Jest: 遅い反応テスト

こんにちはタイロン。 1つのファイルに対して20秒以上でこの問題が発生しました:)
問題は、ルートディレクトリで「jest」を実行するように構成したことです。 そして、Jestがテストのためにチェックしていたサブディレクトリがたくさんあります。 テストのパスを指定すると、今回は10倍以上短縮されました。 そして、私もコーヒープリプロセッサを持っています。 package.json内
「スクリプト」：{
...。
"テスト"： "ジェストパス/ to / modules / to / test"
}

ところで、あなたはコーヒーを前処理していますか、それとも何ですか？ :)

@gothyに戻ってきてくれてありがとう。 私はJSXで通常のJSを使用しています。 例（https://github.com/facebook/jest/tree/master/examples/react）のようにJSXプリプロセッサを介してテストを実行しています。 この例でも、実行に約2.5〜3秒かかります。 jQueryの例は1秒もかかりません。 JSXプリプロセッサは、JSXファイルの処理に非常に時間がかかることを意図していますか？

反応テスト

jQueryテスト

ああ、JSXには使用しませんでした。 このプロセッサでは何も言えません。 多分それは実際には遅いです。 古いものがたくさんある実際のプロジェクトのディレクトリに問題があることがわかりました:)

Coffeescriptプリプロセッサでも同様の問題が発生しました。 ここでの問題は、プリプロセッサが依存関係も処理しようとすることだと思います。 あなたがたまたまたくさんのものを必要とするならば、それは遅くなります。

私は間違いなく冗談で遅いテストを経験します:(

私も同じことを経験しています。 前処理とは関係ないと思います（この小さなファイルでのJSX処理は高速です）。 次のrequireステートメントの1つを除いて、サンプルテストのすべてのコードをコメントアウトしましたが、テストには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プリプロセッサなし

私はJasmineよりもMochaの方が好きで、reactコンポーネントをビルドするgulpfileをセットアップし、それを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を使用しないjestreactの例をテストしたところ、4秒近くから0.75秒になりました。 JSXを使う価値があるかどうか本当に考えさせられます。 大規模なプロジェクトでは、さまざまなパッケージがたくさんない限り、すぐに遅くなります。 プリプロセッサは、その単一のファイルだけでなく、すべての490の要件で実行されるのだろうか。 その単純なコンポーネントに3秒かかるはずはありません。

いずれにせよ、ワークフローを高速化するためにテストが本当に必要です。 少なくとも単一のスイートを実行する方法を理解する必要があります。 ジャスミンでは、「describe」と「it」の代わりに「ddescribe」または「iit」を使用して、単一のテストまたはスイートを実行できました。 ジェストはとてもいいです、私は今ただ速いワークフローが必要です。

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ファイルだけでなく、プリプロセッサを介して実行されます。

最速の解決策は、作業中に変更されたJSXファイルのみを処理するためにgulp、watchify、およびreactを使用することであるように見えます。 そうすれば、実行したいテストのみを指定できるようになります。 このようにして、JSXファイルは1回だけ処理され、実行するテストを制御できます。 このようなものは、テストワークフローにとって本当に素晴らしいでしょう。

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

次に、Watchifyは、これらのテストが依存する変更を監視し、変更のみを処理してから、作業中のテストのみを実行します。

@iamrandys私はあなたに100％同意します。 JestとReactは素晴らしいですが、JSXをJSにコンパイルすることは大きな障害です。 必要なファイル（JSX以外）がJSXプリプロセッサを介して実行されるという問題をGulpがどのように解決するのか興味がありますか？ 次のような提案をしていますか？ http：//blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ？

うん、私はgulpプラグインを備えたある種のキャッシングレイヤーについて考えています
取りかかっている

2014年8月11日8時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の使用は、reactで驚くほど高速です。 投げ入れる
gulp-livereloadを使用して、変更のたびにブラウザを更新すると、
素晴らしい開発環境。 変更を加えて保存すると、ほとんど
開いているすべてのブラウザとすべてのデバイスの変更を即座に確認できます。 今私は
私のTDDにも同じことが必要です。

これはほぼこのようなものですが、hbsfyの代わりにreactifyを使用してください。
https://gist.github.com/benhowdle89/9533185

2:35で月、2014年8月11日には、タイロン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 。

@iamrandysに感謝します。 モカとチャイ（ジャスミンは簡単に代用可能）を使用したクイックリアクションコンポーネントボイラープレートを開発。 テストは非常に迅速であり、Livereloadの追加の利点が得られます。 必要に応じて使用してください。

いずれにせよ、ワークフローを高速化するためにテストが本当に必要です。 少なくとも単一のスイートを実行する方法を理解する必要があります。 ジャスミンでは、「describe」と「it」の代わりに「ddescribe」または「iit」を使用して、単一のテストまたはスイートを実行できました。 ジェストはとてもいいです、私は今ただ速いワークフローが必要です。

あなたは間違いなくit.onlyを書くことができます、そして私はあなたがdescribe.onlyもできると信じています。

カルマはあなたが望んでいることを正確に行い、あなたがしなければならないのは追加することだけです
プロジェクトへのkarma.confファイル。 私はカルマがreactifyをサポートしていることに気づいていませんでした
とbrowserify。 これで、すべてのブラウザで同時にテストできます。
ボイラープレートプロジェクトのPRを作成しました。

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

'npm test'を実行するだけで、karmaがブラウザを起動し、
変化します。

10:35で火、2014年8月12日には、タイロンAvnit [email protected]
書きました：

@iamrandyshttps ：//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回のテストに1秒もかかりません）。 さらに、Karmaは作業中に変更を監視し、複数のブラウザーでコードをテストしますが、Jestの自動モックが大好きです。 rewireifyを使用して手動でスパイを作成するのは余分な作業ですが、完全に制御できます。

ええ、私はあなたを誤解しているかもしれませんが、jsxを含む.jsファイルがあり、プラグマヘッダーに基づいて検出したい場合は、.jsxのチェックを削除することを意味しました。

私のiPhoneから送信された

2014年8月28日には、午前23時45で、タイロンAvnit [email protected]書きました：

興味深いスニペット@sqs。 私が間違っている場合でも、各ファイルを調べて変換する必要があるかどうかを確認する必要はありませんか？ 私は次のことで多くの成功を収めました-react-component-boilerplate。 テストは実際にはかなり迅速に実行されます。

—
このメールに直接返信するか、GitHubで表示してください。

やあ！ 私は冗談のために--watchに取り組んでおり、一般的にこれをより速くしようとしています。 すぐに報告します。

私の最初の実行には約5秒かかります（テストは1つだけで、始めたばかりです）。 その後、追加の実行ごとに約1.2〜1.5秒かかります。

その時間のかなりの量が急いでキャッシュをロードするのに費やされているようです（私のプロジェクトではすでに4メガのファイルです。

--watch作業を楽しみにしていますが、テストを実行するのに1.2秒のロード時間が必要なことが何が起こっているのか疑問に思っていますか？ 速攻が何をしているのか、なぜ冗談がそれを使っているのかについては何も知らないので、私はかなり無知です。

Hasteは、モジュール名が相対的ではなくトップレベルであるCommonJSモジュール形式のフレーバーをサポートします。 つまり、プログラムを実行する前にモジュール（および依存関係）を事前に知る必要があります。そうしないと、ファイルシステムをトラバースして各requireモジュールを探すのが非常に非効率になります。 ただし、ほとんどの人が相対モジュール形式（la node.js）を使用していることを認識しており、（オプションが提供されていない限り）Hasteへの暗黙の依存関係を削除したいので、これにより高速になります。

@amasadそれは素晴らしいです

beforeEachまたはitコールバックで繰り返しではなく、describeコールバックの下で一度ファイル（特に 'react / addons'とテスト中のモジュール）を要求することが大きな違いを生むことがわかりました。

明らかに、私はjsxではなくcoffee-scriptを使用していますが、これにより、プリプロセッサの作業と、 require呼び出しを自動モックするためのjestの作業の両方が節約されます。

__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は、現在の状態では完全に使用できません。 申し訳ありませんが、カルマに切り替えます。

私はカルマ、モカ、チャイ、シノン、再配線、エイリアス化で大きな成功を収めました。 300を超えるテストが1/2秒で実行されます。 何よりもReactは素晴らしいです!!!!! チームはそれを愛し、それを使っていくつかの本当に良いものを開発してきました。 それはとてもきれいでメンテナンス可能です。 私たちが今まで使ったものとは大きく異なります。

自分でこれに遭遇しただけです。 テストの実行速度は_本当に_遅くなります。 遅いテストの問題は、開発者がそれらを無効にするか、一部の時間しか実行しないことです。 何がこれを引き起こしているのか考えていますか？ 手伝いましょうか？

私はこの正確な問題を抱えていました-テストは最初に実行するのに約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はひどく遅いです。 インラインテストと組み込みのモックのアイデアは気に入っていますが、非常に遅いため、モカが恋しくなります。 原因が何であるかわかりません...速度の低下の原因となっているディレクトリツリーを検索していません。 ファイルを直接指定すると、それでも非常に遅いです。

少なくとも遅さの原因について何か考えはありますか？ （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+に短縮します。 この回避策により、reactファイルには拡張子_.jsx/_。react.jsを使用する必要があると思いました。reactifyを使用する場合にも役立つと思います。

正直に言うと、Gruntを通過すると、まだ+20秒の時間が得られていました。
カルマと反応し、合計時間は約+4/5秒です。

ただし、すべてVM内にあります

これについて報告するだけです。 Karma / Mochaとの反応をテストしており、700近くのテストがあり、すべてのテストを実行するのに約4秒かかります。 モックを管理する必要がありますが、それだけの価値はあります。 Reactは驚くべきものでした。 完璧でさわやかに安定しています。 ゲームチェンジャー！ 私たちのチームは、他のものを使用してイメージングすることができませんでした。

私はジェストを速くすることはありませんでした。 モカを使っています。 ジェストが速かったら、私は
代わりにそれを使用したでしょう。

12:17の木、2015年2月5日には、ギル・バーマン[email protected]
書きました：

@iamrandyshttps ：//github.com/iamrandysで説明して
どのようにして冗談をこんなに速くすることができたのか、もっと詳しく教えてください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/jest/issues/116#issuecomment-73097182 。

ありがとう@iamrandys 「どうやって冗談を速くしたの？」を削除しました。 私があなたの投稿を読み間違えたことに気付いた後の質問（しかしあなたは同時に答えました）...とにかく、それは残念です、私は冗談はまだ生産使用の準備ができていないと考えられるべきだと思います。

@haihappenと@darcyadamsによる回避策/変更により、1回のテストでテスト時間を3.5秒から約1秒に短縮できました。 これは、見かけの起動時間も考慮していません。これも約1秒のようです。 これは遅すぎて日常の作業では効率的ではないように思われるので、モカ/カルマのコンボを見てみようと思います。 デフォルトですべてをモックするというJestの哲学は好きですが、メリットはありません。

同じ問題があります。小さなプロジェクトで3つのテストを取得しただけで、3秒かかります。

プロジェクトロードマップの近くでパフォーマンスを改善していますか？

ところで：変更されたファイルに対してのみ単体テストを再実行する（かなりハックな）方法を見つけました。 通常、実行するテストは1つしかないため、これにより、再びかなり高速になります。 私はそれをここに置きました： https ：

Strange Jestは、React.js 2015confで言及されていません。

testPathDirsが原因のようです。 package.jsonで次のように指定します。

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

自動モックを使用している場合は、 @ adjavaherianに注意してください： //github.com/facebook/jest/issues/176

実際、testPathDirsが依存関係をカバーしていない場合、自動モッキングが微妙でイライラする方法で機能することを期待してください。

これらの懸念から、テストのセットアップで何か問題が発生している可能性があると思います。 私はここで間違っているかもしれませんが、私が知る限り、 beforeEachテスト内で他の必要なモジュールと一緒にvar component = React.createFactory(require("component/path"))ようなものを使用しています。 確かに、これはすべてのテストに必要なわけではありません。 つまり、工場は毎回新鮮な部品を生産する必要があります。 requireをbeforeEachブロックの外に移動すると、テスト速度が10倍になります。 残念ながら、その場合、いくつかのテストが奇妙に失敗し、その理由がわかりません。

これが役立つかどうかはわかりません。 考え？

報告されたテスト実行時間から前処理時間が除外されていると便利です。 その作業の大部分が変換ステップからのものである場合、赤を見るのは一種の不公平です。

こんにちは、みんな、

私も同じ問題を抱えています。 実行に約1分かかるテストケースもあります:(

パフォーマンスの問題のプロファイリングをどこから始めればよいかわかりません。ヒントはありますか？

アップデート

私は自分のVM環境でのみ発生するこの問題を修正しました（cf：http：//stackoverflow.com/a/13703132）。 今でもテストは私が期待するよりも遅いですが、浮浪者の修正前よりもはるかに速いです（私のテストスーツでは60秒-> 6秒）

それでも速度が問題になる場合は、モカに移動することをお勧めします。 このフォークで多くの成功を収めました。これは、単純なReact展開から複雑なReact展開のテストをセットアップする方法を説明しています。 https://github.com/adjavaherian/mocha-react私たちは定期的に約3秒で100以上のテストを実行しています。

私はモカが行く方法であることに同意します。 最大約900回のテストで、約4秒かかります。

2015年4月23日には、16:53で、アミールDjavaherian [email protected]書きました：

それでも速度が問題になる場合は、モカに移動することをお勧めします。 このフォークで多くの成功を収めました。これは、単純なReact展開から複雑なReact展開のテストをセットアップする方法を説明しています。 https://github.com/adjavaherian/mocha-react私たちは定期的に約3秒で100以上のテストを実行しています。

—
このメールに直接返信するか、GitHubで表示してください。

同じ経験で、（JSXを使用して）1つのテストだけでJestをセットアップしただけで、約3秒かかります。これは大変なことです。

@iamrandysセットアップの例を示してもよろしいですか？ 完璧なコンボのようです。

@amasad Jestには、babel-loaderがcacheDirectoryオプションで許可するものと同様のコンパイル済みファイルのキャッシュを構築するオプションがありますか？ -https：//github.com/babel/babel-loader#options

私にとって冗談を遅くしているのは、コンパイルではなく、ワーカープールプロセスの起動です。 約4秒かかる最初のテストを除いて、すべてのテストは0.05秒未満で合格します。
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は、テストが遅い最後のインスタンスでした。
私の発見は単なる症状であり、問​​題の根本ではない可能性があります。
しかし、私はそれに適切な分析をする時間がありませんでした。

私のテストは現在次のようになっています。

私の反応テストは遅いです（examplesフォルダーにあるもの）。 私が話しているのは、無反応テストです。

+1

こっちも一緒。 テストは非常に遅いです：がっかり：

問題に直面したのは私だけだと思いました。 Jestを使用するのは初めてで、テスト結果も速くありません。 FacebookがJestを使用してどのようにテストを行うのか疑問に思っていますか？

React EuropeカンファレンスのQ＆AセッションでのReactのみんなへのJestの改善についての私の質問-https：//youtu.be/CRJZBZ_-6hQ？t = 363

Mocha + Sinonに切り替えました。 決して幸せではありませんでした。

2015年8月31日17：45、AlanRubinnotifications @ github.comは次のように書いています。

React EuropeカンファレンスQ＆AでのJest to theReactの人たちについての私の質問
セッション-https：//youtu.be/CRJZBZ_-6hQ？t =

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/jest/issues/116#issuecomment-136394910 。

私は同じ問題を抱えています。 Jestテストには時間がかかるだけで、実行時間は実際には異なります。 それらを並行して実行するか、1つのプロセス（--runInBand）で実行するかは重要ではありませんでした。 ワーカープロセス間のリソース競合ではないようです。

v8プロファイラー（https://github.com/node-inspector/v8-profiler）を使用していくつかのCPUダンプを作成しましたが、ほとんどの時間がモジュールのモックに費やされているようです。 つまり、ユニットテストの実行時間の25％がjest-cli / src / lib / utils.js＃runContentWithLocalBindingsに費やされています。

パフォーマンスの更新はありますか？ es6とbabel-jestでjestを取得しましたが、10秒以上で2つの簡単なテストを実行しています:-(
スピードアップするためにこのスレッドから多くのアイデアを試しましたが、何も機能しませんでした...

すぐにこれに焦点を合わせます。 私たちは今、冗談の仕事に少し圧倒されていますが、それをもっと素晴らしいものにすることを約束します。

コミュニティが支援できるタスクはありますか？

+1

現在の最大の助けは、実際にはドキュメント、Webサイトを改善し、問題を解決し、オープンソースの人々を支援することです。

ビルドパイプラインでJESTテストを高速化するために行ったことの1つは、シングルコアマシンをマルチコアマシンに置き換えることでした。 デフォルトでは、jestは使用可能なハードウェアスレッドと同じ数のワーカーを生成します。 これが利用できない場合は、手動で「-w」（maxWorkers）を使用して遊ぶことができます。 シングルコアでもスピードアップが得られるかもしれません。

最終的に、モジュールのモックは非常にコストがかかり（上記の私のコメントを参照）、実行時間の大部分を引き起こすことがわかりました。

私にとってes6のJestは完全に使用できません。 起動するだけで10秒以上かかり、現在の1つのテストを実行するのに2秒かかります。 カルマに戻って、もっと多くのことを期待していました:(

現在、node-hasteを新しいモジュールリゾルバーに置き換える作業を行っています。これにより、この問題が修正されるはずです。

こんにちは、みんな。 この問題に関するニュースはありますか？

こんにちは、Jestは非Reactテストに適していますか？ 私たちのチームでは、反応アプリと非反応アプリの両方に共通の基準を設定したいと考えています。

Jestは普遍的なテストランナーであり、Reactを使用する必要はありません。 :)例の1つを見てください！

みなさん、こんにちは。ここにいくつかの本当に興味深い情報があります。 また、テストの実行速度が遅いという問題も発生しています。 現在、実行に最大15秒かかる13のテストがあります。

packages.jsonファイルに"testPathDirs": ["<rootDir>/path/to/tests/"]を追加すると、起動時間が大幅に改善されることがわかりました。

@cpojer新しく改善されたモジュールリゾルバーに関する最新情報はありますか？ これがテストをより速く実行するための鍵になることを本当に望んでいます

この作業は＃599で行われています。

ありがとう@ cpojer😀
完成したHaste2を見るのを楽しみにしています

モカを使用した同じテストは、私にとって44msで実行され、冗談は6秒かかりました。

jestを使用する最初の6つのテストファイルをMocha 、 jsdom 、およびsinonを使用するように切り替えるのに約15分かかりました。

皆さん、朗報です。今日は＃599をマージします。ついに、起動の遅さをなくすことができます。

わかりました。これは最終的にJest0.9で修正されるはずです。 これに時間がかかって申し訳ありませんが、Jestにはいくつかの不器用さがありました:)

Reactテスト自体がどのように高速化されたかについては、 https：//github.com/facebook/react/pull/6052を参照してjest-cli@nextとしてタグ付けされています。 解決したら、この問題を解決します。

この新しいバージョンを実行する場合はnpm install jest-cli@next （ jest@next @cpojerではなく）

そうそう、私はいつもこの間違いを犯します:)私は元のコメントを編集しました。

npm install jest-cli@nextを使用してアップグレードした後の@cpojer dontMock指定に問題があります。 つまり、更新前（[email protected]を使用）は、この行は正しく機能します。

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

次に、0.9.0に更新した後、同じ呼び出しでモジュールがモックされます

@steinbachrは、おそらく別の問題に入るはずです。 この問題がFBで発生するのを見たことがないので、再現を提供できれば素晴らしいと思います。

ありがとう@cpojer 、ここで作成され