Jest support

Detection#

Jest projects are detected from jest.config.ts, jest.config.js, jest.config.mjs, jest.config.cjs, jest.config.json, package dependencies such as jest and @jest/globals, and matching test-file conventions.

Test Chronicle also recognises common colocated test layouts and package-level configuration in larger repositories. When Jest shares a repository with Vitest or Playwright, project settings can narrow the Jest scope to the packages that still use it.

Parsed information#

Test Chronicle records test names, file paths, describe groups, line numbers, todo markers, and parameterised patterns from test.each, it.each, and common loop-generated definitions.

The recorded structure helps reviewers move from a dashboard signal back to the source test: current name, parent group, file, line, framework, and the commits where the definition changed. This is useful when a unit test was renamed during refactoring or removed as dead coverage.

Limits and configuration#

Jest projects often include generated snapshots, helpers, fixtures, and migration leftovers. Test Chronicle tracks source test definitions, not snapshot artifacts or runtime-expanded cases. Exclusions should be used for generated test folders or archived packages that should not affect current suite history.

Use repository defaults to review the detected default branch or choose a primary framework, then use test discovery only where automatic behaviour needs help.

Mixed repositories#

Jest can be tracked alongside other supported JavaScript frameworks in one repository. Use framework directory overrides when Jest and Vitest, Playwright, or Cypress files share broad naming conventions.

Framework-aware history makes migration reviews easier. During a Jest-to-Vitest move, teams can see whether tests were genuinely deleted, renamed, or re-created in a different framework instead of relying on raw file counts.