No need to manually trigger any test run, all changes will be monitored and related tests will be run accordingly. It is basically running jest with --watch or --watchAll. This is the default mode prior to v4. Example:

• "jest.autoRun": {"watch": true} => will start the jest with the watch flag and leave all tests at "unknown" state until changes are detected.
• "jest.autoRun": {"watch": true, "onStartup": ["all-tests"]} => will start running all tests upon project launch to update overall project test stats, followed by the jest watch for changes.

Allow users to control test run completely either through commands/menu manually or use vscode's onSave event to automate related test runs:

• fully manual
  • there will be no automatic test run, users will trigger test run by either command or context-menu.
  • Example: "jest.autoRun": "off"
• automatically run tests when test file changed
  • the extension will trigger test run for the given test file upon save.
  • Example: "jest.autoRun": {"watch": false, "onSave": "test-file"}
• automatically run tests when either test or source file changed:
  • the extension will trigger test run for the given test or source file upon save.
  • Example: "jest.autoRun": {"watch": false, "onSave": "test-src-file"}

For parameterized tests, you might see debug codeLens like Debug (2), which indicated there are 2 test candidates can be debugged. In such case, you will be prompted to choose when clicking the debug codeLens. All failed test results will appear in both the hovering message panel and the PROBLEMS area.

By default debug codeLens will appear for failed and unknown tests, to change that and others, please see customization for more details.

In addition to the coverage summary that is shown on the top of the file, each line will be marked by its coverage status according to the coverage formatter configured. There are 3 types of coverage you might see in your source code, distinguished by colors:

• "covered": if the code is covered. Marked as "green" by default.
• "not-covered": if the code is not covered. Marked as "red" by default.
• "partially-covered": Usually this mean the branch (such as if, switch statements) only partially tested. Marked as "yellow" by default.
  • Please note, istanbuljs (the library jest used to generate coverage info) reports switch branch coverage with the first "case" statement instead of the "switch" statement.

You can customize coverage start up behavior, style and colors, see customization for more details.

shows the active workspace has onSave for test file only, and that the workspace stats is out of sync with the code, such as when the source file is changed but the related tests are not run yet.

shows the autoRun will be triggered by either test or source file changes.

This should be the command users used to kick off the jest tests in the terminal. However, since the extension will append additional options at run time, please make sure the command line can pass along these options, which usually just means if you uses npm, add an additional "--" at the end (e.g. "npm run test --") if you haven't already in your script. It is recommended not to add the following options as they are managed by the extension: --watch, --watchAll, --coverage

If your project doesn't live in the root of your repository, you may want to customize the jest.rootPath setting to enlighten the extension as to where to look. For instance: "jest.rootPath": "src/client-app" will direct the extension to use the src/client-app folder as the root for Jest.

Possible status are: [ "fail", "pass", "skip", "unknown"]. Please note that this is a window level setting, i.e. its value will apply for all workspaces.

There are 2 formatters to choose from:

1. DefaultFormatter: high light uncovered and partially-covered code inlilne as well as on the right overview ruler. (this is the default)

2. GutterFormatter: render coverage status in the gutter as well as the overview ruler. (Note, there is an known issue in vscode (microsoft/vscode#5923) that gutter decorators could interfere with debug breakpoints visibility. Therefore, you probably want to disable coverage before debugging or switch to DefaultFormatter)

Besides the formatter, user can also customize the color via jest.coverageColors to change color for 3 coverage categories: "uncovered", "covered", or "partially-covered", for example:

"jest.coverageColors": {
  "uncovered": "rgba(255,99,71, 0.2)",
  "partially-covered": "rgba(255,215,0, 0.2)",
}

the default color scheme below, note the opacity might differ per formatter:

"jest.coverageColors": {
  "covered": "rgba(9, 156, 65, 0.4)",
  "uncovered": "rgba(121, 31, 10, 0.4)",
  "partially-covered": "rgba(235, 198, 52, 0.4)",
}

• definition:

AutoRun =
  | 'off'
  | { watch: true; onStartup?: ["all-tests"] }
  | {
      watch: false;
      onStartup?: ["all-tests"];
      onSave?: 'test-file' | 'test-src-file';
    }

• examples
  • Turn off auto run, users need to trigger tests run manually via run commands and menus:

    "jest.autoRun": "off"

  • Run all the tests in the workspace upon extension startup, followed by jest watch run for subsequent test/src file changes.

    "jest.autoRun": {
      "watch": true, 
      "onStartup": ["all-tests"]
    }

  • Only run tests in the test file when the test file itself changed. It will not run all tests for the workspace upon start up, nor triggering any test run when the source file changed.

    "jest.autoRun": {
       "watch": false, 
       "onSave": "test-file"
    }

  • Like the one above but does run all tests upon extension start up

    "jest.autoRun": {
      "watch": false, 
      "onSave": "test-file",
      "onStartup": ["all-tests"]
    }

• migration rule from settings prior to v4:
  • if "jest.autoEnabled" = false => manual mode: "jest.autoRun": "off"
  • if "jest.runAllTestsFirst" = false => "jest.autoRun": {"watch": true }
  • if no customization of the 2 settings and no "jest.autoRun" found =>

  "jest.autoRun": {
     "watch": true, 
     "onStartup": ["all-tests"]
  }

This usually mean the extension is not able to start jest process for you. First check the Jest OUTPUT channel or developer console to see what is the actual error (see self-diagnosis).

If it is related to the run time environment, such as

env: node: No such file or directory

The issue is probably not related to this extension. If this only happened occasionally after launch or you saw vscode warning about shell start up slow, try to simplified the env files, restart vscode or reload windows. See Resolving Shell Environment is Slow.

If you see error about not able to find jest or some other jest related runtime error: if you can run jest from terminal then you can use the "Run Setup Wizard" button in the error panel to help resolving the configuration issue, see Setup Wizard for more details. There could be other causes, such as jest test root path is different from the project's, which can be fixed by setting jest.rootPath. Feel free to check out the customization section to manually adjust the extension if needed.

By default the extension will run all tests when it is launched followed by a jest watch process. If you have many resource extensive tests or source files that can trigger many tests when changed, this could be the reason. Check out jest.autoRun to see how you can change and control when and what tests should be run.

If your test file happen to have parameterized tests, i.e. test.each variations, please make sure you have jest version >= 26.5.

If the above did not resolve your issue, please see the self-diagnosis below that could show more insight of why the test and result could not be matched.

If your can execute jest tests on command line but vscode-jest was not running as expected, here is what you can do to find out more information:

• See jest process output in the "OUTPUT" channel, which is usually named after the workspace folder, such as Jest (your-workspace-name). Or you can click on Jest label on status bar to show Jest Output window. This will show you the jest run output and the errors.

• Turn on the debug mode to see more internal debugging message:
  • set "jest.debugMode": true in .vscode/settings.json
  • restart vscode-jest or reload the window (via Reload Window command)
  • open the developer tool (via Help > Toggle Developer Tools menu), you should see more information including how we extract jest config and spawn jest processes.

Hopefully most issues would be pretty obvious after seeing these extra output, and you can probably fix most yourself by customizing the jest.jestCommandLine and others.