Live Test Runner

Save a file → the affected Jest or Vitest tests run → results show up in the editor. You don't need a terminal or any config changes.

Quick start

1. Open a Jest or Vitest project — a single folder, a monorepo or a multi-root workspace (see Monorepos).
2. Click the beaker icon in the Activity Bar. Tests are discovered right away.
3. Click ▶ Start Testing. The full suite runs once.
4. Edit and save. The affected tests rerun automatically.

Test Explorer

Shows the sidebar tree of every test file, suite and test.

• Instant tree: test files are parsed statically (Babel AST) when the extension starts, so nothing has to run first.
• Discovery cache: parsed results are cached per project and keyed by file modification time, so reopening a project is fast.
• Live updates: creating, editing or deleting a test file updates the tree.
• Dynamic tests: test.each and template-literal names appear as a template that fills in with the real cases after a run.
• Coverage tab: project totals plus a per-file list. Click a row to open the file.

Test files match *.test.* or *.spec.* with js, ts, jsx, tsx, mjs or cjs. node_modules is skipped.

Reruns on save

• Debounced per file (onSaveDebounceMs, default 300 ms).
• Files run in batches across parallel Jest processes. Results stream in file by file.
• If an instrumented batch returns no results, those files are retried with plain Jest, one at a time. This is logged as a warning.

Editor integration

Results panel

Opens in the bottom panel and has three columns: test list · console output (tabs per level: log / info / warn / error) · errors.

• Select a file, suite or test to scope the output and errors to it.
• Output is stored per scope. Jest reports console output per file, so a single test only has its own output after you rerun that test on its own. Until then it shows a placeholder; output from other scopes is never copied in. Vitest says which test or suite printed each line, so with Vitest every test shows its own output right away.
• Each log line has a copy button.

Code coverage

Coverage is collected during normal runs. There's no extra pass or command.

• Badge: Stmts · Branch · Fns · Lines in the Explorer.
• Hover a line to see the covering tests and which branch arms were missed (Jest and Vitest).
• Stale overlay: a grey tint on a saved file until its rerun finishes.
• Files no test imports count as 0%, so totals cover the whole project.

Debugging

▷ Debug starts a VS Code Node debug session for exactly that test or suite: Jest runs in band, Vitest runs with --no-file-parallelism and no timeouts (child processes attach automatically). Breakpoints in tests and source files work as usual.

Vitest

Vitest projects work like Jest ones: open the folder, click ▶ Start Testing. The framework is detected from the project (a vitest dependency or a vitest.config.*, and no Jest config).

• Versions: Vitest 3 or newer is fully supported. Vitest 1–2 run with results only (no test listing, related tests or line numbers). Vitest 5 needs Node ≥ 22.12 on your PATH.
• Your config wins: the extension runs the project's own Vitest with its config, plus the config flags from your test script (--config, --project, --root, …). Files outside include are not run.
• Console output per test: Vitest says which test or suite printed each line, so every test shows its own output after any run.
• Failures: the expected / received diff and the source-mapped line. A failing beforeAll shows its real error and marks the file failed.
• Coverage uses Vitest's own provider. Install @vitest/coverage-v8 (or -istanbul, whichever your config names); without it the log says once that coverage is off. Nothing is written into your project's coverage/ folder.
• Projects: a config with test.projects runs once from the root; Vitest runs every project. Browser-mode projects need real browsers, so they are left out unless you turn on vitestIncludeBrowserProjects or your test script picks projects itself.
• Execution trace (on by default, vitestTrace): the extension records which lines each test runs — the coverage hover lists the covering tests, and saving a source file reruns only the tests that ran it (by name; a test file where every test did runs whole, with fresh coverage). It adds a small Vite plugin through a wrapper config in its own temp folder; your config, plugins and setup files apply as usual, and fn.toString() still returns the code you wrote. TypeScript and JSX lines are mapped back to your source, and so are .vue, .svelte, .astro and .marko components (script and template lines, through their Vite plugin's source map). Vitest 3 vitest.workspace.* files and type-check (*.test-d.ts) files are fine.
• When the trace is off — the setting is off, Vitest is older than 3, or a run with the wrapper failed (the batch is then rerun as configured and the log says why, once) — saving a source file reruns the test files that import it (vitest related), live and with fresh coverage. Browser-mode projects (opt-in) always run without it. Saving vitest.config.* restarts the session.
• Not yet: the Timeline Debugger.

Monorepos & multi-root workspaces

Every test project in the workspace is detected when you open it. None runs until you start it.

• Project switcher: the row at the top of the Explorer (web ▾ ● running ✓120 ✗2) lists every project with its state. Pick one and the tree, Results panel and status bar switch to it. Gutter icons, inline durations, CodeLens and coverage bars always show each file's own project — open a file of another package and you see its results; ▶ Run / ▷ Debug there run in that package. Also: Select Project in the Command Palette.
• Start / Stop act on the project shown. The others keep running — and rerunning on save — in the background; switch back to see their progress.
• How many at once: maxRunningProjects (auto = 2, or 1 on machines with ≤ 4 CPU cores or less than 8 GB of memory (total RAM)). Starting one more asks you to stop a running project first and names the running ones. Stop All Projects stops them all.
• Vitest projects: a package whose config has test.projects is one project; its files are grouped by Vitest project name in the tree.
• Pin one root: Select Project Root (or liveTestRunner.projectRoot) limits Live Test Runner to that folder, exactly as before 3.1; choose "Detect all projects" to go back.
• The status bar shows the selected project and how many run: Live Tests: web · ✅ 12 passed · 2 running.

Jest and Vitest in one project

A project with a Jest config and its own vitest.config.* (e.g. while migrating) runs each test file with its own framework — binary, config, flags, coverage. A vitest dependency alone, or a vite.config.*, does not count: such projects stay Jest.

• The Explorer groups the files by framework; the switcher shows jest + vitest; the status bar splits the counts: ✅ 8 passed · Jest 5 · Vitest 3.
• Saving a source file reruns the dependent tests of both frameworks, each by its own execution trace (Vitest falls back to vitest related when its trace is off). Saving either config restarts the session.
• Coverage: a source file tested by both shows the lines either framework ran.
• Stop kills both frameworks' processes. "Covering tests" on hover list tests of both frameworks; the Timeline debugger works for the Jest files only.
• In a monorepo each package is still its own project; only a package with both configs is mixed.

Timeline Debugger (preview)

Re-runs one test with full instrumentation, then lets you replay it step by step. Jest only — not available for Vitest yet.

• Play / step / scrub through each executed line.
• Variable values shown as ghost text in the editor.
• Sidebar with State, Watch and Call Stack. Use Add to Watch from the hover.
• Console output tied to the step that produced it.

Open it from a test in the Results panel. Leave it with the exit button.

Commands

Command Palette → type Live Test Runner.

Settings

All under liveTestRunner.*.

Logs & troubleshooting

Two output channels

Levels

error something broke and needs action · warning degraded but recovered (fallbacks, files that failed to run) · info milestones and run summaries · debug / trace details, hidden by default

Change the level: Output panel → pick Live Test Runner → ⚙ → Set Log Level. Or Command Palette → Developer: Set Log Level…. The level also applies inside the Jest process, so debug detail from instrumentation shows up too.

Reading a session

[info] [Extension] Live Test Runner v2.0.3 · VS Code 1.95.0 · win32-x64 · Node 20.18.0
[info] [Extension] Project root: c:\work\shop
[info] [Discovery] Discovered 412 test(s) in 58 file(s) in 0.9s (55 from cache, 3 parsed)
[info] [Session] Session started — 58 test file(s) · framework: jest · root: c:\work\shop
[info] [Session] Run #1 full suite — 58 file(s) · 409 passed · 3 failed · 21.4s — failing: cart.test.ts
[info] [Session] Run #2 save cart.ts — 2 file(s) · 31 passed · 0 failed · 2.2s

• Run #N numbers each run. The Test Output channel has a matching ──── Run #N ──── separator.
• b7 (batch) and jest#12 (process) tags link debug lines to raw output.
• Identical lines in a row are collapsed into "previous message repeated N more times".

Common warnings

Reporting a bug

1. Set the log level to Debug and reproduce the problem.
2. Run Copy Diagnostic Report. It opens and copies a Markdown report with versions, project setup and the last 300 log lines.
3. Check it for anything private, then attach it to the issue.

Support & limits

Jest covers babel-jest, ts-jest and @swc/jest; Create React App (react-scripts 4 / 5) has its Jest config extracted automatically. Vitest 3+ is fully supported, Vitest 1–2 run with results only; the framework is detected from the project (a project that lists Vitest but configures Jest runs on Jest).

Any UI framework. React, Preact, Solid, Lit, Angular and Qwik code is plain JS / TS. Vue, Svelte, Astro and Marko components are compiled by your project's own Jest transformer (vue-jest, svelte-jester…) or Vite plugin, and the extension maps them back to their own lines: saving a component reruns the tests that use it, the coverage hover lists the tests that ran each of its lines, and coverage counts it (an untested component counts from its <script>). Other file types count too when your tests load them — an Angular templateUrl, an HTML file imported with ?raw, a template a plugin reads: saving one reruns the tests that use it. More generally: any extension in your Jest config's moduleFileExtensions (e.g. Angular .html templates) reruns its tests on save, and the Vitest trace reaches any file a Vite plugin compiles. With Jest, coverage of a Vue component counts its <script> block only (as jest --coverage does — vue-jest maps only that), but template lines still show the tests that rendered them. Jest's ESM mode is picked up from your test script (NODE_OPTIONS=--experimental-vm-modules jest) or .npmrc (node-options=--experimental-vm-modules) — needed for ESM-only projects and Svelte 4+ with svelte-jester; if a file still fails to load as an ES module, the log says what to change.

• Single-test reruns use --testNamePattern, so tests with overlapping names can run together.
• Jest captures console output per file; per-test output needs an individual rerun. Vitest attributes output per test.
• Instrumented runs raise testTimeout to at least 30 s to absorb the instrumentation overhead.

How a run works

• Jest always runs in a spawned child process, never inside the extension host.
• The live reporter appends one JSON line per finished file. The extension polls that file, so results stream in.
• One pass collects results, coverage counters and line hits together.
• Instrumentation messages reach the log through a small protocol: stderr lines [LTR:<level>] msg.

Where things appear in VS Code

Architecture

• Observer pattern: SessionManager pushes events to IResultObservers. New UI = new observer.
• Adapter pattern: one adapter per framework in runner plus one in the extension.
• One source of truth: ResultStore for results, trace files on disk for trace indexes.
• Isolation: each VS Code window gets its own session-<pid>-<ts> temp folder.
• Projects: one ProjectContext per test project (its stores, discovery, framework services and session); the views show the selected one.

More detail: architecture.md · developer-guide.md

Known issues

All known bugs, with root-cause analysis and suggested fixes, are tracked in bugs-and-issues.md. The open ones:

• In the Jest monorepo, jest-runtime's own tests fail under the session run though they pass with plain Jest (BUG-43).
• Tests that write files into the project can race with batches running at the same time; the batch is retried file by file, so results are right but slower (BUG-44).