メインコンテンツへスキップ
Version: Next

トラブルシューティング

おやおや、うまくいきませんか？ Jest についての問題を解決するのにこのガイドをご利用下さい。

理由は分からないがテストが失敗する​

Try using the debugging support built into Node. Place a debugger; statement in any of your tests, and then, in your project's directory, run:

node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]

このコマンドでJestは外部からのデバッガと接続できる状態のNodeプロセス上で実行されます。 プロセスはデバッガが接続されるまでポーズすることに注意して下さい。

To debug in Google Chrome (or any Chromium-based browser), open your browser and go to chrome://inspect and click on "Open Dedicated DevTools for Node", which will give you a list of available node instances you can connect to. Click on the address displayed in the terminal (usually something like localhost:9229) after running the above command, and you will be able to debug Jest using Chrome's DevTools.

ChromeDeveloperToolsが表示され、Jest の CLIスクリプトの１行目にブレークポイントが設定されます（これは開発者ツールを開くための時間を設けて、その前に Jest が実行されてしまうのを防ぐためのものです）。 次の実行に進むには画面の上部右側にある再生ボタンのようなボタンをクリックします。 When Jest executes the test that contains the debugger statement, execution will pause and you can examine the current scope and call stack.

note

The --runInBand cli option makes sure Jest runs the test in the same process rather than spawning processes for individual tests. 通常Jestはプロセスをまたいで並列にテストを実行しますが、同時に複数のプロセスをデバッグするのは困難だからです。

VS Codeでデバッグする​

There are multiple ways to debug Jest tests with Visual Studio Code's built-in debugger.

組み込みのデバッガを追加するには、前述した形でテストを実行して下さい。

node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]

Then attach VS Code's debugger using the following launch.json config:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "Attach",
      "port": 9229
    }
  ]
}

自動的に起動してテストを実行するプロセスに追加するには、以下の構成を使用して下さい:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/.bin/jest",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

もしくは Windows の場合は以下を使用してください：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

If you are using Facebook's create-react-app, you can debug your Jest tests with the following configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug CRA Tests",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
      "args": [
        "test",
        "--runInBand",
        "--no-cache",
        "--env=jsdom",
        "--watchAll=false"
      ],
      "cwd": "${workspaceRoot}",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

More information on Node debugging can be found here.

WebStormでのデバッグ​

WebStorm has built-in support for Jest. Read Testing With Jest in WebStorm to learn more.

キャッシュ関連の問題​

Jestがコードを変換するスクリプトの変更や、Babelのアップデートを認識できていませんか？

Retry with --no-cache. Jestはテスト実行の高速化のために変換されたモジュールファイルをキャッシュします。 If you are using your own custom transformer, consider adding a getCacheKey function to it: getCacheKey in Relay.

Promiseが解決されない​

promiseが全く解決されない場合、このエラーが投げられるでしょう:

- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.

最も多い原因はPromiseの実装が競合していることです。 Consider replacing the global promise implementation with your own, for example globalThis.Promise = jest.requireActual('promise'); and/or consolidate the used Promise libraries to a single one.

If your test is long running, you may want to consider to increase the timeout by calling jest.setTimeout

jest.setTimeout(10_000); // 10 second timeout

Watchman関連の問題​

Try running Jest with --no-watchman or set the watchman configuration option to false.

Also see watchman troubleshooting.

Dockerおよび/またはCIサーバ上でテストが極端に遅くなる​

While Jest is most of the time extremely fast on modern multi-core computers with fast SSDs, it may be slow on certain setups as our users have discovered.

Based on the findings, one way to mitigate this issue and improve the speed by up to 50% is to run tests sequentially.

In order to do this you can run tests in the same thread using --runInBand:

# Using Jest CLI
jest --runInBand

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --runInBand

Another alternative to expediting test execution time on Continuous Integration Servers such as Travis-CI is to set the max worker pool to ~4. Travis-CIに特定すると、テストの実行時間を半分にできます。 Note: The Travis CI free plan available for open source projects only includes 2 CPU cores.

# Using Jest CLI
jest --maxWorkers=4

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --maxWorkers=4

If you use GitHub Actions, you can use github-actions-cpu-cores to detect number of CPUs, and pass that to Jest.

- name: Get number of CPU cores
  id: cpu-cores
  uses: SimenB/github-actions-cpu-cores@v2
- name: run tests
  run: yarn jest --max-workers ${{ steps.cpu-cores.outputs.count }}

Another thing you can do is use the shard flag to parallelize the test run across multiple machines.

coveragePathIgnorePatterns seems to not have any effect.​

Make sure you are not using the babel-plugin-istanbul plugin. Jest は Istanbul をラップするため、カバレッジを収集するのにどのファイルを使用するのかを Istanbul に伝えます。 When using babel-plugin-istanbul, every file that is processed by Babel will have coverage collection code, hence it is not being ignored by coveragePathIgnorePatterns.

Defining Tests​

Tests must be defined synchronously for Jest to be able to collect your tests.

As an example to show why this is the case, imagine we wrote a test like so:

// Don't do this it will not work
setTimeout(() => {
  it('passes', () => expect(1).toBe(1));
}, 0);

When Jest runs your test to collect the tests it will not find any because we have set the definition to happen asynchronously on the next tick of the event loop. This means when you are using test.each you cannot set the table asynchronously within a beforeEach / beforeAll.

まだ解決しませんか？​

See Help.