Vitest support

Detection#

Vitest projects are detected from vitest.config.ts, vitest.config.js, package dependencies, and matching test-file conventions.

Test Chronicle looks for common Vitest naming patterns such as .test.ts, .spec.ts, and colocated tests. If a monorepo mixes Vitest unit tests with Playwright or Cypress end-to-end tests, framework detection keeps each source family separate.

Parsed information#

Test Chronicle records test names, file paths, describe groups, line numbers, parameterised patterns, and todo markers.

Supported source patterns include test, it, describe, test.each, it.each, and common loop-generated definitions. The dashboard can then show both the current Vitest snapshot and the Git commits that changed it.

Limits and configuration#

Vitest workspace projects and environment settings are treated as context for detection, not as duplicate test definitions. Runtime cases generated by data tables remain grouped as parameterised source definitions so repository history stays readable.

Use testing classification when Vitest files include a mix of unit, component, and integration tests. Path rules help the Health Score and testing-type filters reflect the way the project is organised.

Mixed repositories#

Vitest can be tracked alongside another supported framework in the same repository. Framework filters keep the resulting history and current test snapshot distinguishable in the dashboard.

Use a framework directory override when a monorepo or non-standard structure makes automatic detection too broad.

For everyday review, this means a team can inspect whether fast unit coverage is growing while browser-level coverage changes more slowly, instead of treating every JavaScript test as one undifferentiated count.