Connecting AI edits to the tests that relate to the change

Try it yourself first

1. 1. Check your existing tests once

   Confirm that your usual test command runs and that the sources you will change are imported by the tests. The example below is for a repository that already has Vitest.

2. 2. Run once, specifying the changed sources

   Replace src/cart.ts and src/price.ts in the example with your actual changed files. Add --run to avoid watch mode so the command exits.

3. 3. See whether it catches the failures you need

   Try a change that includes a known failure and check the selected test names and failure reasons. If zero targets are found, do not assume success; check paths, import relationships and configuration.

./node_modules/.bin/vitest related --run src/cart.ts src/price.ts

The paths are examples for illustration. This is not a command to run as-is in a repository that has not adopted it. The hooks and performance in this example have not been measured.

Connecting it to automation

1. 1. Record the set of changes

   In the proposal using PostToolUse Edit/Write, edited paths are collected. Changes made through Bash, code generation or external processes do not pass through this route, so prepare another way to capture them.

2. 2. Decide when to run

   With Stop, tests can run all at once when Claude finishes responding. Even if there are several edits in a long turn, it does not detect the end of each one. Decide based on whether you need immediate feedback.

3. 3. Hand off safely to a single run

   Design it to merge identical paths and pass file names to the runner as an array of arguments, not by string concatenation. Do not mix other sessions or simultaneous edits, and leave changes that grow during a run for the next set. This is a design matter to decide before adoption.

4. 4. Return the result and separate the next actions

   On failure, return the test names and failure reasons to Claude and recheck after the fix. Treat only a passing set as complete, and separate a missing runner or a timeout from test failures. Set a limit so the same failure does not repeat forever.

How to read the result

Passed

The selected tests passed.
Check for tests that were not selected, and for the full CI that is still needed separately.

Failed

A test related to the change failed.
Return the failure reason and recheck the same target after the fix.

Zero targets

It cannot distinguish between no target existing and a selection that missed it.
Check the source paths, import relationships and runner configuration.

Could not run

Possible causes include a missing command, an environment problem or a timeout.
Treat it as an environment problem and avoid retrying the same run forever.

What to check before adopting

• If changes through Bash or generation are also needed, consider using FileChanged or before-and-after diffs in the current official documentation, and check support in the version you use.
• Separate a person's existing uncommitted changes from the changes made by the AI this time.
• For tests that depend on dynamic imports, configuration files, or external data and integrations, check whether related selection alone is enough.
• Decide the execution time limit, the retry limit for the same failure, and how to handle changes that grow during a run.
• Do not skip existing required tests, CI or review because of this workaround.

On November 1, 2026, we edited this by matching the original request and replies against the official specifications of Anthropic and Vitest. It is not an article reporting a hook adopted in a real environment, nor one verifying shorter test times.