Testing classification

What this controls#

Classification assigns every discovered spec file to one testing level:

• Unit
• Integration
• Component
• E2E
• Unknown

These levels drive the testing pyramid, testing-level filters, file totals, and related analytics. Classification does not change which files are discovered.

Automatic behaviour#

Test Chronicle first looks for testing-level keywords in the repository path or filename. When no path keyword is present, it uses the framework's default level.

Built-in framework defaults are:

Classification precedence#

The first successful source wins:

Path overrides are evaluated from top to bottom. When two rules overlap, the first matching rule wins.

Recognised path keywords#

Keyword matching is case-insensitive and recognises path or filename boundaries.

For example, tests/integration/payments.test.ts is Integration even when its framework normally defaults to Unit.

When to add an override#

Use a path rule when one directory or naming convention should take priority over the framework default.

Use a framework fallback when most files for a framework play a different role in your project. For example, set Vitest to Integration when the majority of Vitest files exercise connected services.

Avoid using a framework fallback to correct one exceptional directory; use a path rule instead.

Configure classification#

Open Project Settings → Classification.

1. Review detected frameworks and their effective levels.
2. Add path rules for specific repository paths.
3. Reorder rules when patterns overlap.
4. Change framework fallbacks only when the framework's general role differs from its built-in default.
5. Save classification.

Existing specs and analytics are reclassified from their stored paths after saving. Another sync is not required.

Path rule matching#

Rules are repository-relative and case-insensitive.

• A value without * is treated as a path fragment.
• * matches characters within one path segment.
• ** matches recursively across path segments.

tests/integration/**
src/**/*.component.test.tsx
packages/payments/contract-tests

Use the narrowest useful pattern and place more specific rules before broad rules.

Examples#

One framework with multiple roles#

Keep Vitest's fallback as Unit and add:

tests/integration/** → Integration
src/components/**/*.test.tsx → Component

Integration-first Vitest project#

Set the Vitest framework fallback to Integration, then add a narrower Unit rule:

src/domain/** → Unit

Overlapping rules#

Given these rules:

packages/store/e2e/** → E2E
packages/store/** → Integration

The E2E rule must appear first or the broader Integration rule will claim those files.

Reset and troubleshoot#

Select Reset to automatic, then save, to remove path rules and configured framework fallbacks.

If a file has an unexpected level:

1. Check the first matching path rule.
2. Look for recognised keywords in the full file path.
3. Review the configured framework fallback.
4. Confirm the spec's detected framework.

SyncConfig fragment#

{
  "testLevelMappings": {
    "frameworkDefaults": {
      "vitest": "integration"
    },
    "pathOverrides": [
      {
        "level": "unit",
        "patterns": ["src/domain/**"]
      },
      {
        "level": "component",
        "patterns": ["src/components/**/*.test.tsx"]
      }
    ]
  }
}