{"dataset":{"id":"00000000-0000-0000-0000-000000000033","slug":"vitest-best-practices","name":"Vitest best practices","description":"Source-linked guidance on Vitest fundamentals: writing and organizing tests, mocking, code coverage, snapshot testing, and watch-mode filtering. Scoped to Vitest as documented at vitest.dev; not a general JavaScript testing corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Watch mode and test filtering","sourceUrl":"https://vitest.dev/guide/filtering.html","text":"vitest starts in watch mode by default in development and in run mode in CI (when process.env.CI is present); vitest watch and vitest run select the mode explicitly. In watch mode, Vitest searches the module graph and only reruns tests related to changed files. To narrow a run, pass a filename substring to run only matching test files, or use -t (or --testNamePattern) with a regex matched against the full test name — the enclosing describe names and the test name joined with ' > '. Appending :lineNumber to a full file path runs the test containing that line, and tags in test options plus --tags-filter run categorized tests. Inside files, .only focuses a test or suite and skips everything else there, and Vitest fails the run if .only appears in CI unless the allowOnly option permits it; .skip disables a test and .todo marks a placeholder. Filters apply per test file, so pass a file path alongside the filter to avoid loading every file. Scope: Vitest. Reviewed October 4, 2026.","id":"vitest-best-practices:Watch mode and test filtering","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Snapshot testing","sourceUrl":"https://vitest.dev/guide/snapshot.html","text":"Snapshot tests make sure the output of functions does not change unexpectedly. expect(value).toMatchSnapshot() compares the value against a reference snapshot file stored alongside the test; a mismatch fails the test, meaning either the change is a bug to fix or the reference snapshot needs updating. Snapshot artifacts should be committed alongside code changes and reviewed as part of code review. toMatchInlineSnapshot() instead stores the snapshot inside the test file, and Vitest modifies the test file directly to fill it in. In watch mode, pressing the u key updates a failed snapshot; the --update or -u CLI flag does the same. In CI (when process.env.CI is truthy) Vitest does not write snapshots by default, and mismatched, missing, or obsolete snapshots fail the run. Rendering is powered by @vitest/pretty-format, the snapshotFormat option configures formatting, and custom serializers or custom snapshot matchers extend it; with async concurrent tests, use expect from the local Test Context. Scope: Vitest. Reviewed October 4, 2026.","id":"vitest-best-practices:Snapshot testing","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Code coverage with V8 or Istanbul","sourceUrl":"https://vitest.dev/guide/coverage.html","text":"Vitest supports native code coverage via v8 and instrumented coverage via istanbul; both are optional, v8 is the default, and test.coverage.provider selects the tool. The support packages are @vitest/coverage-v8 and @vitest/coverage-istanbul, and Vitest prompts to install the matching one at startup. The v8 provider needs a V8-based runtime such as NodeJS, Deno, or a Chromium browser and collects coverage at runtime through node:inspector or the Chrome DevTools Protocol, so source files run as-is with no pre-instrumentation; since v3.2.0, AST-based remapping makes its reports as accurate as Istanbul's. Its limits: collection cannot be scoped to specific modules, loading many different modules can make it slower than Istanbul, and non-V8 runtimes such as Firefox or Bun are unsupported — even so, the guide marks v8 as the recommended option. Istanbul instruments the source before running, works on any JavaScript runtime, has been battle-tested since 2012, and can limit instrumentation to specific files, which can make it faster than V8 in some cases. Scope: Vitest. Reviewed October 4, 2026.","id":"vitest-best-practices:Code coverage with V8 or Istanbul","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Mocking with the vi helper","sourceUrl":"https://vitest.dev/guide/mocking.html","text":"Mocking is provided through the vi helper, imported from vitest or accessed globally when the globals configuration is enabled; the core methods are vi.fn, vi.mock, and vi.spyOn. A vi.mock call is hoisted to the top of the file and always executes before all imports. To mock part of a module, pass an async factory that awaits importOriginal and spreads the original module while overriding selected exports — but this only mocks external access, so a module's internal calls to its own exports still reach the original implementation. Always clear or restore mocks before or after each test run to undo mock state changes (see the mockReset docs). vi.setSystemTime mocks Date and Temporal time and does not reset automatically; vi.stubGlobal and vi.stubEnv likewise persist unless the unstubGlobals or unstubEnvs config options are enabled or vi.unstubAllGlobals and vi.unstubAllEnvs are called. Note that the vi.spyOn patterns for mocking module exports do not work in Browser Mode; the documentation lists a workaround under its Browser Mode limitations. Scope: Vitest. Reviewed October 4, 2026.","id":"vitest-best-practices:Mocking with the vi helper","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Writing and organizing tests","sourceUrl":"https://vitest.dev/guide/learn/writing-tests.html","text":"Tests are defined with the test function and assertions with expect, both imported from vitest; it is an alias of test and behaves identically, so teams can pick whichever reads better. Group related tests with describe into named suites — nesting is supported, but keep it shallow because deeply nested tests are harder to read, and a flat list is often enough for simple modules. By default Vitest discovers any file containing .test. or .spec. in its name (the patterns **/*.test.{ts,js,mjs,cjs,tsx,jsx} and **/*.spec.{ts,js,mjs,cjs,tsx,jsx}), searching all subdirectories, so tests can live co-located with the source or in a dedicated directory; the include and exclude config options customize discovery. TypeScript works out of the box through Vite's on-the-fly transform with no extra compiler to install, but Vitest does not type-check during the test run — run tsc or vitest typecheck separately when full type checking is needed. Scope: Vitest. Reviewed October 4, 2026.","id":"vitest-best-practices:Writing and organizing tests","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}