Vitest 5.1, released on November 2nd, incorporates vitest run --since-last-run: runs only the tests whose files changed since its own last execution, plus any test that failed previously and still doesn’t pass. It’s experimental, doesn’t need Git, and the first run is complete: savings start from the second run onwards.
The version also brings interactive snapshot review and a --last-failed flag. We’ll see them below, but the main thing is test selection, because it changes the command you run dozens of times a day.
What is Vitest and how does it differ from Jest?
Vitest is the native test runner for Vite: it uses an API compatible with Jest’s (describe, it, expect, with vi instead of jest for mocks and timers), is open source with an MIT license, and if you’re already using Vite, it reuses your configuration and transformation pipeline instead of maintaining a separate one. That’s why searching “vitest vs jest” usually ends up the same: migrating is, in large part, changing imports.
With 5.1, Vitest adds snapshot review one by one (something Jest already offered in its interactive mode) and test selection that compares against your last execution instead of against Git.
How do you run only the tests affected by a change in Vitest?
Use --since-last-run. On the first run, Vitest runs all tests and records the files each one loaded, including dynamic imports, mocks, setup files, and snapshot files. On each subsequent run, a test reruns if:
- one of its recorded files is newer than its last execution, or was deleted;
- it doesn’t have a record yet (new test files always run);
- it failed last time and hasn’t passed since, even if the fix is in a file outside its record.
Each run updates the records of the tests it ran, so the reference follows your executions, not a commit.
vitest run --since-last-run
Records are saved in Vitest’s cache. To restart them:
vitest run --clearCache
The next --since-last-run after that becomes a full run again.
Underneath, the feature relies on two other experimental pieces, experimental.recordDependencies and a new VCS provider called mtime; that’s why the whole set carries the experimental tag. At the time of publishing this note, the guide for this feature (affected tests) was only on the next version’s documentation site (main.vitest.dev), not on the stable documentation.
--changed or --since-last-run: which one should you use?
They answer different questions: --changed compares against a Git reference; --since-last-run compares against your last test execution.
vitest run --changed # uncommitted changes, staged and unstaged
vitest run --changed HEAD~1 # the last commit plus uncommitted changes
vitest run --changed origin/main # everything on this branch
The limitation of --changed: it needs a Git repository and, once a change is committed, it stops counting as changed, even if you’ve never run tests against it. --since-last-run doesn’t care about commits.
Vitest’s own documentation recommendation:
| Goal | Use |
|---|---|
| A branch, before opening or updating a pull request | --changed origin/main |
| The commits you’re about to push | --changed <upstream> |
| Uncommitted changes in a Git repo | either one |
| Changes since your last test execution, committed or not | --since-last-run |
| A directory without Git, or with a history you don’t control | --since-last-run |
Rule of thumb: --changed for a shared reference (CI, pull requests) and --since-last-run for your personal cycle.
What tests can --since-last-run miss?
The documentation mentions two blind spots:
- Files that no test loaded last time. A new
.envor a new file in__mocks__isn’t in anyone’s record, so modifying it doesn’t trigger anything. - Modification dates in the past. A checkout or a decompressed archive can leave files with old mtimes, and the flag compares mtimes.
The solution is the same for both: run the full suite (vitest run) once before finishing.
How do you use --since-last-run with AI agents?
Agents commit midway through a task, work in containers and temporary worktrees, and launch a new process for each command: exactly the cases where --changed loses track. Vitest’s documentation suggests adding this to your project’s AGENTS.md:
- After a change, run `vitest run --since-last-run` to test only what the change affects.
- Before you finish, run `vitest run` once for the whole suite.
The second line is what covers the blind spots from the previous section.
How do you rerun only failing tests in Vitest?
With the new --last-failed, which reruns only the tests that failed in the last execution (it reads them from the results cache) and combines with filters:
vitest run --last-failed -t login
If a file failed outside a test (in beforeAll or during collection), the entire file runs.
How do you review and update snapshots one by one in Vitest?
In watch mode, the u key keeps updating all failed snapshots at once. The new interactive review, inspired by Insta’s review command, goes through them one by one: press i to open it, a to accept the new snapshot, and r to keep the previous one. After the last one, Vitest writes the accepted snapshots and reruns the affected files. It covers inline snapshots, .snap files, file snapshots, and ARIA snapshots in Browser Mode.
What else changes in Vitest 5.1?
- Trace View in Browser Mode becomes stable and is enabled by default (
browser.traceView.mode, with'failure-only'as the default value);browser.traceView.enabledbecomes obsolete. - Vitest coverage with
istanbul: the provider leaves Babel and switches to Oxc via Rolldown; the team reports 5 to 10 times faster instrumentation (figure from the project itself). - Browser Mode port: the default port changes from
63315to23315. Configureapi.portif anything depends on the previous one.
How do you get started with --since-last-run?
Update to Vitest 5.1 and run the flag twice: the first records, the second selects.
vitest run --since-last-run # full run, creates the record
# edit a file
vitest run --since-last-run # only what that edit touched
What about you? How long does your full suite take today and when do you run it?
- I always run the full suite
- I use watch mode or --changed
- I filter by hand by file or by name
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your response gets published here.
Related: Code-review-graph: Your Agent Reviews Only the 15 Files That Matter, not the 27,000