Jest: 慢反应测试

嗨，泰伦。 一个文件有 20 秒以上的问题:)
问题是我已经配置为只在根目录中运行“jest”。 并且 Jest 正在检查许多子目录以进行测试。 为测试指定路径现在减少了 10 倍以上。 我也有一个咖啡预处理器。 在 package.json 中
“脚本”：{
....
“测试”：“开玩笑的路径/到/模块/到/测试”
}

顺便说一句，你是预处理咖啡还是什么？ :)

感谢您回复我@gothy。 我在 JSX 中使用常规 JS。 我只是像示例一样通过 JSX 预处理器运行我的测试（https://github.com/facebook/jest/tree/master/examples/react）。 该示例还需要大约 2.5 - 3 秒才能运行。 jQuery 示例只需不到一秒钟。 JSX 预处理器在处理您的 JSX 文件时是否意味着要花费这么多时间？

反应测试

jQuery 测试

啊，我没有将它用于 JSX。 不能对这个处理器说什么。 也许它实际上很慢。 我在一个带有大量旧东西的真实项目中发现了我的目录问题:)

我在使用 Coffeescript 预处理器时遇到了类似的问题。 我认为这里的问题是预处理器也尝试处理您的依赖项。 如果您碰巧需要很多东西，它就会变慢。

我肯定也经历过开玩笑的​​缓慢测试:(

我正在经历同样的事情。 我认为这与预处理无关（对这个小文件的 JSX 处理速度很快）。 我注释掉了示例测试中的所有代码，除了以下 require 语句之一，测试仍然需要 4 秒。 一旦我将它们注释掉，测试就需要 0.1 秒。 我做了一些挖掘，看起来 HasteModuleLoader 必须处理 490 个必需的包（_shouldMock()），并且在您需要 react/addons 时不要模拟它们。

var React = require('react/addons');

或者

var CheckboxWithLabel = require('../CheckboxWithLabel.js');

我删除了以下var React = require('react/addons');并仍然通过预处理器运行文件。 我可能得到了 0.2 秒的改进。 如果我删除了预处理器，我会得到以下结果：

使用 JSX 预处理器

没有 JSX 预处理器

我更喜欢 Mocha 而不是 Jasmine，并决定设置一个 gulpfile 来构建 react 组件，然后通过 mocha 测试套件（下面的片段）运行它。

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

它仍然需要使用 reactify 预处理 JSX 文件，但消除了慢速测试的警告消息。 所以运行时间仍然不到 2 秒，但实际测试大约是 32 毫秒。 仍在决定使用 JSX 是否值得。

哦，你说得对。 我测试了不使用 JSX 的 jest react 示例，它从接近 4 秒缩短到 0.75 秒。 让我真正思考是否值得使用 JSX。 在一个大项目中，除非我有很多不同的包，否则它会很快变慢。 我想知道预处理器是否在所有 490 个要求上运行，而不仅仅是那个单个文件。 对于那个简单的组件，不可能需要 3 秒。

无论哪种方式，我真的真的需要我的测试对我的工作流程来说是快速的。 我仍然需要弄清楚如何至少运行一个套件。 在 jasmine 中，我可以使用“ddescribe”或“iit”代替“describe”和“it”来运行单个测试或套件。 Jest 太好了，我现在只需要一个快速的工作流程。

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 

@jeffchan是对的。 所有必需的代码都通过预处理器运行，而不仅仅是 JSX 文件。

看起来最快的解决方案是在工作时使用 gulp、watchify 和 react 来仅处理更改的 JSX 文件。 然后我们将能够仅指定我想要运行的测试。 这样 JSX 文件只处理一次，我可以控制运行哪些测试。 对于测试工作流程来说，这样的事情会非常好。

gulp jest --tests "Checkbox*,*Form*"

Watchify 然后将监视这些测试所依赖的任何更改，然后仅处理更改，然后仅运行我正在使用的测试。

@iamrandys我 100% 同意你的看法。 Jest 和 React 很棒，但是将 JSX 编译成 JS 是一个很大的障碍。 只是好奇 Gulp 将如何解决您需要的文件（非 JSX）通过 JSX 预处理器运行的问题？ 您是否建议类似以下内容 - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ？

是的，我正在考虑使用 gulp 插件的某种缓存层
工作

自2014年8月11日08:35，泰隆Avnit [email protected]写道：

@iamrandys https://github.com/iamrandys我 100% 同意你的看法。 开玩笑和
React 很棒，但是将 JSX 编译成 JS 是一个很大的障碍。 只是
好奇 Gulp 将如何解决拥有所需文件的问题（非
JSX) 通过 JSX 预处理器运行？ 你有什么建议吗
像下面这样？ ——
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
直接回复此邮件或在 GitHub 上查看
https://github.com/facebook/jest/issues/116#issuecomment -51749798。

确切地说，使用 gulp 和 watchify 的反应速度非常快。 投放
gulp-livereload 在每次更改后刷新你的浏览器，你有一个
惊人的开发环境。 你做任何改变，保存，你几乎
立即查看所有打开的浏览器和所有设备中的更改。 现在我
我的 TDD 只需要同样的东西。

大约是这样，但是使用 reactify 而不是 hbsfy。
https://gist.github.com/benhowdle89/9533185

2014 年 8 月 11 日星期一上午 2:35，Tyrone Avnit通知@github.com
写道：

@iamrandys https://github.com/iamrandys我 100% 同意你的看法。 开玩笑和
React 很棒，但是将 JSX 编译成 JS 是一个很大的障碍。 只是
好奇 Gulp 将如何解决拥有所需文件的问题（非
JSX) 通过 JSX 预处理器运行？ 你有什么建议吗
像下面这样？ ——
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

—
直接回复此邮件或在 GitHub 上查看
https://github.com/facebook/jest/issues/116#issuecomment -51749798。

谢谢@iamrandys。 开发了一个使用 Mocha 和 Chai 的快速反应组件样板（茉莉花可以很容易地替代）。 测试速度非常快，您可以获得 Livereload 的额外好处。 随意使用。

无论哪种方式，我真的真的需要我的测试对我的工作流程来说是快速的。 我仍然需要弄清楚如何至少运行一个套件。 在 jasmine 中，我可以使用“ddescribe”或“iit”代替“describe”和“it”来运行单个测试或套件。 Jest 太好了，我现在只需要一个快速的工作流程。

你绝对可以写it.only ，我相信你也可以写describe.only 。

Karma 正是您想要的，您所要做的就是添加一个
karma.conf 文件添加到您的项目。 我没有意识到 karma 支持 reactify
和浏览器。 现在，您可以同时在所有浏览器中进行测试。
我为你的样板项目创建了一个 PR。

https://github.com/iamrandys/react-component-boilerplate/tree/karma

只需运行“npm test”，karma 就会启动你的浏览器并监视
变化。

2014 年 8 月 12 日，星期二，上午 10:35，Tyrone Avnit通知@github.com
写道：

谢谢@iamrandys https://github.com/iamrandys。 开发了一个快速
反应组件样板
https://github.com/TYRONEMICHAEL/react-component-boilerplate使用
摩卡和柴（茉莉花可以很容易地替代）。 测试非常
快速，您可以获得 Livereload 的额外好处。 随意使用。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/facebook/jest/issues/116#issuecomment -51931532。

使用以下 preprocessor.js 来避免 JSX 转换非 JSX 文件。 照原样，它只处理包含/** @jsx前缀的.jsx文件。 如果您想对.js文件进行 JSX 转换，只需删除||之前的 if 条件的第一部分（以便仅保留src.slice ...条件）。

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

不过还是有点慢。

有趣的片段@sqs。 纠正我 如果我错了，但它是否仍然不必查看每个文件并检查是否需要转换它？ 我在以下方面取得了很大的成功 - react-component-boilerplate 。 测试实际上运行得非常快。

非常好。 这将时间从 9.3 秒减少到 4.7 秒。 这是单次测试。 我仍然需要继续使用 Karma，因为它的速度要快得多（100 次测试只需不到一秒钟）。 另外，Karma 会在你工作时观察变化，并会在多个浏览器中测试你的代码，但我喜欢 Jest 的自动模拟。 使用 rewireify 手动创建间谍是额外的工作，但您可以完全控制。

是的，我可能误解了您的意思，但这就是我的意思，如果您有带有 jsx 的 .js 文件并希望根据 pragma 标头进行检测，则删除对 .jsx 的检查。

从我的iPhone发送

在2014年8月28日，在23:45，泰隆Avnit [email protected]写道：

有趣的片段@sqs。 纠正我 如果我错了，但它是否仍然不必查看每个文件并检查是否需要转换它？ 我在以下方面取得了很大的成功 - react-component-boilerplate。 测试实际上运行得非常快。

—
直接回复此邮件或在 GitHub 上查看。

你好！ 我正在--watch开玩笑，并且通常试图让这一切变得更快。 将很快回来报告。

我的第一次运行大约需要 5 秒（我只有一个测试，我才刚刚开始）。 之后，每次额外运行大约需要 1.2-1.5 秒。

看起来相当多的时间都花在了加载快速缓存上（对于我的项目来说，它已经是一个 4 兆的文件。

我很期待--watch工作，但我也想知道发生了什么需要 1.2 秒的加载时间来运行测试？ 我不知道匆忙在做什么以及为什么 jest 使用它，所以我很无能为力。

Haste 支持一种 CommonJS 模块格式，因为模块名称是顶级的而不是相对的。 这意味着我们需要在运行程序之前提前知道模块（和依赖项），否则遍历文件系统以在每个require上查找模块的效率会非常低。 然而，我们意识到大多数人都在使用相对模块格式（a la node.js），我们希望消除对 Haste 的隐式依赖（除非提供了一个选项），这应该使它更快。

@amasad听起来很棒。 我已经尝试过 intern.js，它从 cmd 行运行常规单元测试，以在几毫秒内完成。 你认为 jest 可以这么快吗？ 您是否考虑过提取 automocking 部分，以便在其他框架（如 jasmine 或 mocha）中使用它？

我发现需要文件（尤其是“反应/插件”和正在测试的模块）在描述回调下一次，而不是在beforeEach或it回调中重复产生巨大的差异。

显然，我使用的是咖啡脚本而不是 jsx，但这既节省了预处理器的工作，也节省了自动模拟require调用的笑话。

__tests__/login_fields.coffee (3.013s) （哎哟！）

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

但是，它变得更快......
__tests__/login_fields.coffee (0.604s) （不错）

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...

我的测试时长为 14 秒，即使在使用了迄今为止推荐的所有优化之后也是如此。 即使有 16GB RAM 和 SSD。 Jest 在当前状态下完全无法使用。 抱歉，切换到 Karma。

我在 karma、mocha、chai、sinon、rewireify 和 aliasify 方面取得了巨大的成功。 超过 300 次测试以每秒 1/2 的速度运行。 最棒的是 React 太棒了！！！！！！ 团队喜欢它，并且一直在用它开发一些非常好的东西。 它是如此干净和易于维护。 与我们曾经使用过的任何东西都有很大的不同。

我自己就遇到了这个。 测试运行 _REALLY_ 慢。 缓慢测试的问题在于开发人员禁用它们或仅在部分时间运行它们。 知道是什么原因造成的吗？ 我能提供什么帮助？

我有这个确切的问题 - 测试最初运行大约需要 17 秒，然后在缓存后运行 4 秒。 事实证明，我的构建目录和外部模块没有被正确排除。 将 testPathDirs 配置选项设置为指向源目录将运行时间减少到 0.5 秒。

这对我使用 React v0.12+ 有效：

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};

也刚开始使用 Jest - 只是测试常规 JavaScript 模块（没有 JSX / React）并且 Jest 非常慢。 我喜欢内联测试和内置模拟的想法，但它太慢了，让我想念 Mocha。 我不确定罪魁祸首是什么......它没有搜索导致速度缓慢的目录树。 如果我直接指定文件，它仍然超级慢。

至少对缓慢的原因有任何想法吗？ （我没有使用 JSX/CoffeeScript；自动模拟已关闭）

最初的例子从来没有对我有用，因为第一个参数总是返回 true。

var ReactTools = require('react-tools');
var MAGIC = "/** <strong i="6">@jsx</strong> ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

@culshaw @haihappen感谢您提供好的解决方法，将 10 次以上的测试缩短为 2 次以上。 这个变通办法让我觉得也许我们应该为我们的反应文件使用扩展名 _.jsx/_.react.js，我认为在使用 reactify 时它也可能有帮助。

老实说，通过 Grunt 我仍然得到 +20s 的时间，得到
React 与 Karma 一起工作，总时间约为 +4/5 秒。

虽然都在虚拟机内

只是为了报告这个。 我们一直在用 Karma/Mocha 测试 react，我们有接近 700 个测试，运行所有测试大约需要 4 秒。 我们确实必须管理模拟，但这是值得的。 React 太棒了。 完美无瑕，令人耳目一新。 游戏改变者！ 我们的团队无法使用其他任何方法进行成像。

我从来没有让 Jest 跑得快。 我正在使用摩卡咖啡。 如果 Jest 很快，我
会用它代替。

2015 年 2 月 5 日星期四下午 12:17，Gil Birman通知@ github.com
写道：

@iamrandys https://github.com/iamrandys你介意解释一下吗
更详细地说明你是如何做到这么快开玩笑的？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/facebook/jest/issues/116#issuecomment -73097182。

谢谢@iamrandys我已经删除了我的“你是怎么开玩笑的？” 在意识到我误读了您的帖子（但您同时回复了）之后提出的问题……无论如何，这是一种耻辱，我想应该仍然认为开玩笑还没有准备好用于生产。

@haihappen和@darcyadams的解决方法/更改帮助我将单个测试的测试时间从 3.5 秒缩短到大约 1 秒。 这并没有考虑到明显的启动时间，它似乎也是大约 1 秒。 这在日常工作中似乎太慢了，所以我想我会看看 mocha/karma 组合。 我喜欢 Jest 默认嘲笑一切的哲学，但好处就是没有 atm。

我有同样的问题：我在一个小项目中只进行了 3 个测试，它们需要 3 秒钟。

是否在项目路线图附近的任何地方提高性能？

顺便说一句：我找到了一种（非常hackish）的方法来重新运行单元测试，只针对已更改的文件。 这使它们再次变得非常快，因为通常只有一个测试要运行。 我把它放在这里： https :

在 React.js 2015 会议上没有提到 Strange Jest。

testPathDirs 似乎是罪魁祸首。 在 package.json 中这样指定：

  "jest": {
    "unmockedModulePathPatterns": [
      "./node_modules"
    ],
    "scriptPreprocessor": "./preprocessor.js",
    "testDirectoryName": "tests",
    "testPathDirs": ["tests"]
  }

@adjavaherian如果您使用自动https :

事实上，如果您的 testPathDirs 没有覆盖您的依赖项，那么预计自动模拟会以微妙和令人沮丧的方式中断。

这些担忧让我觉得我们的测试设置可能有问题。 我在这里可能是错的，但据我所知，我们都在使用类似的东西： var component = React.createFactory(require("component/path"))以及beforeEach测试中的其他必需模块。 当然，这对所有测试都不是必需的。 我的意思是工厂每次都应该生产新的组件。 如果我将要求移到beforeEach块之外，测试速度会增加 10 倍。 不幸的是，在那种情况下，有些测试奇怪地失败了，我不知道为什么。

不确定这是否有帮助。 想法？

如果预处理时间被排除在报告的测试执行时间之外，那就太好了。 当大部分工作来自转型步骤时，看到红色有点不公平。

嗨，大家好，

我有同样的问题。 我什至有一些测试用例需要大约 1 分钟才能运行:(

我不知道从哪里开始分析性能问题，有什么提示吗？

更新

我修复了这个仅出现在我的 VM 环境中的问题（参见：http://stackoverflow.com/a/13703132）。 现在测试仍然比我预期的要慢，但比 vagrant 修复之前快得多（我的测试服 60 秒 -> 6 秒）

如果速度仍然是一个问题，我建议转向 Mocha。 我们在这个 fork 上取得了很多成功，它解释了如何为简单到复杂的 React 部署设置测试。 https://github.com/adjavaherian/mocha-react我们定期在大约 3 秒内运行 100 多个测试。

我同意摩卡是要走的路。 多达近 900 次测试，大约需要 4 秒。

2015 年 4 月 23 日下午 4:53，Amir Djavaherian [email protected]写道：

如果速度仍然是一个问题，我建议转向 Mocha。 我们在这个 fork 上取得了很多成功，它解释了如何为简单到复杂的 React 部署设置测试。 https://github.com/adjavaherian/mocha-react我们定期在大约 3 秒内运行 100 多个测试。

—
直接回复此邮件或在 GitHub 上查看。

相同的经验，我只用一个测试（使用 JSX）设置了 Jest，大约需要 3 秒，这是很多。

@iamrandys你介意展示一个你的设置示例吗？ 似乎是完美的组合。

@amasad Jest 是否有一个选项可以为编译的文件建立一个缓存，类似于 babel-loader 在 cacheDirectory 选项中允许的内容？ - https://github.com/babel/babel-loader#options

对我来说，让 jest 变慢的不是编译，而是工作池进程的启动。 我的所有测试都在 0.05 秒内通过，除了第一个测试大约需要 4 秒。
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee它不只是想发送 PR 以将其作为选项？ 我认为我们不应该默认启用它，因为有时无法知道何时破坏缓存。 例如，如果您更改编译器选项，缓存应该重置。 另一种选择是除了缓存之外还有一个重置缓存选项。

@doodzik你确定是工作池而不是node-haste说明和读取模块吗？

@amasad我所做的是测量运行jest每一步完成所需的时间。
而node-worker-pool是测试缓慢的最后一个实例。
可能我的发现只是症状，而不是问题的根源。
但我没有时间给它一个适当的分析。

我的测试目前看起来像这样：

我的反应测试很慢（示例文件夹中的那些）。 我说的是非反应测试。

+1

同样在这里。 测试非常非常慢：失望：

我以为只有我遇到了这个问题。 这是我第一次使用 Jest，我也没有得到快速的测试结果。 想知道 Facebook 如何使用 Jest 进行测试？

我在 React Europe 会议问答环节对 React 人员的 Jest 改进问题 - https://youtu.be/CRJZBZ_-6hQ?t=363

切换到摩卡+诗浓。 从未如此快乐。

2015 年 8 月 31 日 17:45，Alan Rubin [email protected]写道：

我在 React Europe 会议 Q&A 上对 React 人员的 Jest 问题
会话 - https://youtu.be/CRJZBZ_-6hQ?t=363

—
直接回复此邮件或在 GitHub 上查看
https://github.com/facebook/jest/issues/116#issuecomment -136394910。

我也有同样的问题。 Jest 测试需要很多时间，而且执行时间实际上各不相同。 是并行运行还是仅在一个进程中运行 (--runInBand) 并不重要。 这似乎不是工作进程之间的资源争用。

我使用 v8 分析器 (https://github.com/node-inspector/v8-profiler) 创建了一些 cpu 转储，发现大部分时间似乎都花在了模拟模块上。 即我的单元测试 25% 的执行时间花在 jest-cli/src/lib/utils.js#runContentWithLocalBindings 中。

任何性能更新？ 刚刚用 es6 和 babel-jest 开玩笑，但在 > 10 秒内运行了 2 个简单的测试:-(
从这个线程尝试了很多想法来加速，但没有任何效果......

我们很快就会关注这个问题。 我们现在有点忙于 Jest 的工作，但我们致力于让它更棒。

社区有什么可以帮助的任务吗？

+1

现在最大的帮助实际上是改进文档、网站和解决问题并帮助开源人员。

我们为加快构建管道中的 JEST 测试所做的一件事是用多核机器替换我们的单核机器。 默认情况下，jest 会产生与硬件线程一样多的工作线程。 如果这对您不可用，您可以手动使用 '-w' (maxWorkers)。 您也可以在单核上获得加速。

最终我们发现模拟模块非常昂贵（见我上面的评论）并导致大部分执行时间。

Jest with es6 对我来说完全无法使用。 仅启动需要 10 多秒，然后运行我目前的单个测试需要 2 秒。 我期待更多，切换回业力:(

我们目前正在努力用新的模块解析器替换 node-haste，这应该可以解决这个问题。

大家好。 有没有关于这个问题的消息？

嗨，Jest 适合非 React 测试吗？ 希望在我们的团队中为反应和非反应应用程序制定一个通用标准。

Jest 是一个通用的测试运行器，你绝对不需要使用 React。 :) 看看其中一个例子吧！

大家好，这里有一些真正有趣的信息。 我也遇到测试运行缓慢的问题。 我目前有 13 个测试需要大约 15 秒才能运行。

我确实发现将"testPathDirs": ["<rootDir>/path/to/tests/"]到我们的 packages.json 文件有助于显着改善启动时间。

@cpojer你有没有关于新的和改进的模块解析器的更新？ 我真的希望这将是让测试运行得更快的关键

这项工作正在#599 中进行。

谢谢@cpojer 😀
我期待看到完成的Haste2

对我来说，使用 mocha 的相同测试在 44 毫秒内运行，而 jest 用了整整 6 秒。

我花了大约 15 分钟将使用jest初始 6 个测试文件切换为使用Mocha 、 jsdom和sinon 。

大家好消息，我今天要合并#599，它应该最终消除缓慢的启动。

好的，这最终应该在 Jest 0.9 中得到修复。 抱歉，这花了这么长时间，但 Jest 中有一些小丑 :)

请参阅https://github.com/facebook/react/pull/6052 ，了解 React 测试本身是如何加速的。 如果您想尝试此改进，请查看 #599 中的评论。 它目前被标记为jest-cli@next直到查看开源中的人们是否可能遇到任何错误。 我会在解决后关闭这个问题。

npm install jest-cli@next如果你想运行这个新版本（而不是jest@next @cpojer）

哦，是的，我总是犯这个错误:) 我编辑了我的原始评论。

@cpojer使用npm install jest-cli@next升级后我在指定dontMock遇到问题。 我的意思是，在更新之前（使用 [email protected]）这行工作正常：

jest.dontMock('../../../../fixtures');

然后在更新到 0.9.0 后，相同的调用导致模块被模拟

@steinbachr可能应该进入一个单独的问题。 如果你能提供一个repro就好了，在FB上还没有看到这个问题！

谢谢@cpojer ，这里创建的