Vitest Is Collecting Unrelated Tests? Start with the File List

If Vitest reports a failure in a test file you do not recognize, inspect the file path before changing assertions, timeouts, or worker settings. A test collected from a tool's cache needs a different fix from a failing test in your application.

The useful question is specific: which files did this invocation discover, and which of them belong in the suite? Here is how to check that boundary, using the configuration in design-to-nativewind as a concrete example.

Get the discovery list before editing the config

Vitest provides a command for listing matching test files:

pnpm exec vitest list --filesOnly

Run it from the same working directory as the failing invocation, with the same config and project-selection flags if you use them. The official CLI documentation describes --filesOnly; this is a reader procedure, not output from a reproduction performed for this article.

Keep the list, then identify an unexpected path and an expected path. For example, a result under .trunk/ would be a reason to inspect that directory, rather than a reason to assume the runner is broken. On a checkout with Trunk, this command shows whether these particular entries are links and where they point:

ls -ld .trunk/tools .trunk/out

In the checkout inspected for this article, both entries point into ~/.cache/trunk. That establishes a filesystem link to a cache. It does not establish that the current Vitest invocation traverses it or admits tests from its target. The discovery list is the next piece of evidence needed for that claim.

If the failure names a file absent from that list, check whether a listed test imports it or the failing command selected a different configuration or project. Narrowing discovery does not remove imports from tests you keep.

What this project's config actually establishes

The project's current test configuration contains these two settings:

include: ['src/**/*.test.ts'],
exclude: ['node_modules', 'build', '.trunk'],

The checked-in tests fit that include pattern. They include src/core/__tests__/names.test.ts, which tests component-name conversion, and extract.test.ts, which supplies mock Figma nodes to the extraction function.

Both the config comment and the project's build/test guidance record the reason for the boundary: avoiding unrelated tests reached through .trunk cache symlinks. Those are records of the project's rationale. The original failure has not been reproduced for this article, so they do not prove a regression in a particular Vitest version or a problem with every root-based configuration.

In fact, Vitest's include documentation resolves patterns relative to root, which defaults to the working directory. Using that root is supported behavior. The issue to diagnose is whether your patterns admit files that do not belong in your suite.

Narrow discovery without dropping your own tests

Copying src/**/*.test.ts would silently omit tests in tests/, files named .spec.ts, and files ending in .test.tsx. Start with your actual directories and naming conventions, then make the boundary explicit.

For example, a repository with TypeScript and TSX tests under both src/ and tests/ could use the following configuration:

import { configDefaults, defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    include: ["src/**/*.{test,spec}.{ts,tsx}", "tests/**/*.{test,spec}.{ts,tsx}"],
    exclude: [...configDefaults.exclude, "**/.trunk/**", "build/**"],
  },
});

This is an adaptation example, not the configuration committed in design-to-nativewind. Add any other real test locations and extensions before adopting it, and preserve existing project-specific exclusions. If your intended tests already need a broad include pattern, extending the exclusions for an identified unwanted directory may be the smaller change.

The spread of configDefaults.exclude matters: setting test.exclude in a config replaces Vitest's defaults. The official exclude documentation recommends that spread when extending them. Likewise, do not spread the broad default include back into a configuration whose purpose is to restrict discovery to named directories.

Verify both sides of the change

Run the same listing command after the edit, with the same working directory and selection flags. Compare the complete before and after lists, then check:

• The specific unrelated paths you identified are gone.
• Every intended test location and filename convention still appears, including any .spec or TSX tests.
• The result is not an empty list made green by allowing a run with no tests.

Then run the project's normal test command. In design-to-nativewind, package.json defines test as vitest run. A passing run checks the collected suite's behavior; comparing file lists checks whether it was the intended suite. Neither check replaces the other.

The transferable fix is a discovery boundary supported by the file list. Whether that boundary is src/, several package directories, or an exclusion depends on the tests your repository actually owns.