Vitest interview questions and answers

Vitest is a test runner built on Vite. It reuses your Vite config, plugins and transforms, so TypeScript, JSX and ESM work without extra setup; its watch mode is fast because it uses Vite's module graph to rerun only affected tests. Its API is largely Jest-compatible (describe, it, expect, vi for mocks), so migrations are usually small.

vi.fn() creates a mock function, vi.spyOn(obj, 'method') spies on a method, and vi.mock('module', factory) replaces a module (hoisted to the top of the file). vi.importActual keeps the real module for partial mocks. vi.mocked() gives typed access to mocks, and vi.restoreAllMocks() cleans up.

Use React Testing Library with environment: 'jsdom' (or happy-dom), add @testing-library/jest-dom/vitest in a setup file for matchers, render components, query by role and interact with user-event. Browser Mode can run the same tests in a real browser.

vi.mock calls are hoisted to the top of the file, before imports, so they cannot use variables declared later. vi.hoisted(() => ({ fetchUser: vi.fn() })) creates values that are also hoisted, so mock factories can reference them.

It reads vite.config (or vitest.config) so aliases, plugins (React, TypeScript paths) and transforms match the app. Test options go under the test key. This avoids maintaining separate Babel or Jest transform settings.

In vitest.config.ts (or the test field of vite.config.ts) set environment: 'jsdom' or 'happy-dom' for DOM tests, 'node' otherwise, setupFiles for global setup (such as jest-dom matchers), globals: true if you want Jest-style globals, and include/exclude patterns. Per-file environments can use a comment at the top of the file.

It runs tests in a real browser (through Playwright or WebdriverIO providers) instead of a simulated DOM, so layout, CSS and browser APIs behave like production. It suits component tests where jsdom falls short, and provides interactivity APIs similar to user-event.

vi.useFakeTimers() then vi.advanceTimersByTime(ms), vi.runAllTimers() or vi.setSystemTime(date); restore with vi.useRealTimers(). Async versions such as advanceTimersByTimeAsync let pending promises settle between timers.

Run vitest run --coverage with a provider: v8 (fast, uses V8's built-in coverage) or istanbul (instrumentation). Configure reporters, include/exclude and thresholds under test.coverage.

Use async tests with await, and await expect(promise).resolves / .rejects.toThrow(). expect.assertions(n) ensures async assertions actually ran. vi.waitFor retries a callback until it passes.

Use MSW with setupServer in a setup file for realistic HTTP mocking, or vi.spyOn(globalThis, 'fetch').mockResolvedValue(new Response(JSON.stringify(data))) for simple cases. Restore mocks after each test.

vi.stubEnv('API_URL', 'http://test') and vi.stubGlobal('matchMedia', fn) set values for a test; vi.unstubAllEnvs() and vi.unstubAllGlobals() (or the unstubEnvs config option) restore them.

Each test receives a context object; test.extend({ db: async ({}, use) => { const db = await create(); await use(db); await db.close(); } }) defines fixtures that set up and tear down resources only for tests that use them.

Filter by file name on the command line, by test name with -t, use .only or .skip, tags with --project, or run tests related to changed files with --changed. In watch mode, press keys to filter interactively.

test.concurrent (or describe.concurrent) runs tests in the same file in parallel. Use the expect from the test context for snapshots and assertions so results are attributed to the right test.

Write bench('name', () => {...}) in *.bench.ts files and run vitest bench, which uses Tinybench to report operations per second and compare implementations.

One config can define several projects (for example unit tests in node, component tests in jsdom or the browser, different packages in a monorepo), each with its own settings, run together with one command and one report.

Writing tests inside the source file under if (import.meta.vitest) { ... }. They run with Vitest but are removed from production builds through a define setting. Handy for small utility functions.

Test files run in parallel in worker threads or child processes (pool: 'threads' | 'forks' | 'vmThreads'); tests within a file run in sequence unless marked concurrent. --shard splits files across CI machines.

toMatchSnapshot() writes to a __snapshots__ file, toMatchInlineSnapshot() writes into the test, and toMatchFileSnapshot() compares with a separate file; update with -u. Review snapshot changes like code.

Install Vitest, move config to vitest.config.ts, replace jest. calls with vi. (or enable globals), adjust module mocks (factories must return objects with named exports, default for default exports), switch setup files, and fix any CommonJS-only patterns.

Vite defines import.meta.env in tests too; set values with vi.stubEnv or .env.test files, since Vitest loads env files for the test mode.

vi.fn() creates a standalone mock function; vi.spyOn(obj, 'method') wraps an existing method and can be restored; vi.mock('module') replaces a whole module for the file.

Use renderHook from React Testing Library, read result.current, wrap updates in act, and provide context with the wrapper option.

Vitest isolates files by default (separate module graphs). Within a file, reset mocks with restoreMocks or mockReset config, clean the DOM after each test, and avoid module-level mutable state.

It repeatedly runs a function and asserts on its result until it passes or times out, useful for waiting on asynchronous conditions without fixed sleeps.

By default CSS is processed lightly or ignored in tests (configurable with css options), and CSS Modules can return class names. Static assets resolve to paths, as in Vite.

vitest --ui opens a browser dashboard showing test files, results, module graphs and console output, with filtering and reruns.

Yes, vitest typecheck (or --typecheck) runs type-level tests using expectTypeOf and assertType through the TypeScript compiler, useful for libraries with complex types.

Use reporters such as junit for CI dashboards, github-actions for annotations, json or html, set with --reporter or the reporters config option.

1. Ajest
2. BviCorrect answer
3. Cmock
4. Dsinon

Why: vi mirrors Jest's jest object.

1. AViteCorrect answer
2. BBabel only
3. Cesbuild alone
4. DWebpack

Why: It reuses Vite's config and transforms.

1. Avi.mock is hoisted above other codeCorrect answer
2. BIt speeds up tests
3. CIt enables watch mode
4. DIt mocks timers

Why: Factories can use hoisted values.

1. Ajest.config
2. Bpackage.json scripts
3. CThe Vite configCorrect answer
4. Dbabel.config only

Why: Same pipeline as the app.

1. Avitest/dom
2. B@vitest/matchers
3. C@testing-library/jest-dom/vitestCorrect answer
4. Djest-dom/register

Why: Add it in a setup file.

1. Aruntime: 'web'
2. Benvironment: 'jsdom'Correct answer
3. Cbrowser: false
4. Ddom: true

Why: jsdom or happy-dom simulate the DOM.

1. Avi.restore
2. Bvi.spyAll
3. Cvi.importActualCorrect answer
4. Dvi.unmock

Why: Spread the actual module into the factory.

1. Av8 and istanbulCorrect answer
2. Bc8 only
3. Cnyc only
4. Dlcov only

Why: Pick one under test.coverage.provider.

1. ABrowser ModeCorrect answer
2. BNode mode
3. CSSR mode
4. DWatch mode

Why: Browser Mode uses Playwright or WebdriverIO.

1. AAll tests
2. BOnly tests affected by the changed modulesCorrect answer
3. CNothing
4. DOnly failed tests ever

Why: It uses Vite's module graph.

1. Avi.stubEnvCorrect answer
2. Bprocess.env only
3. Cvi.env
4. Dvi.setEnv

Why: Restore with unstubAllEnvs.

1. Atest.extendCorrect answer
2. Bvi.fixture
3. CbeforeAll only
4. Ddescribe.fixture

Why: Set up and tear down per test.

1. Avi.parallel
2. Bdescribe.async
3. Ctest.concurrentCorrect answer
4. Dtest.parallel

Why: Use context expect.

1. Avitest --bench-only
2. Bnpm bench
3. Cvitest benchCorrect answer
4. Dvitest perf

Why: Uses Tinybench.

1. A--name-only
2. B-tCorrect answer
3. C--grep-files
4. D--only

Why: Matches test names.

1. Alegacy: true
2. Bglobals: trueCorrect answer
3. Cjest: true
4. Dcompat: 'jest'

Why: Otherwise import them from 'vitest'.

1. Avi.clock
2. BDate.mock
3. Cvi.now
4. Dvi.setSystemTimeCorrect answer

Why: It sets the current time for Date.

1. A__tests__ only
2. BInside if (import.meta.vitest)Correct answer
3. CIn package.json
4. DIn vite.config

Why: They are stripped from production builds.

1. Aexpect.reject(p)
2. Bp.should.fail
3. Cexpect(p).toThrow()
4. Dawait expect(p).rejects.toThrow()Correct answer

Why: Same as Jest.

1. ArenderHookCorrect answer
2. BmountHook
3. Cvi.hook
4. DtestHook

Why: From Testing Library.

1. Avi.waitFor only
2. Bexpect.eventually
3. Cexpect.pollCorrect answer
4. Dexpect.retry

Why: No fixed sleeps.

1. Avi.stubGlobalCorrect answer
2. Bvi.global
3. CglobalThis.mock
4. Dvi.window

Why: Restored with unstubAllGlobals.

1. Adot
2. Bverbose
3. Ctap
4. Dgithub-actionsCorrect answer

Why: Shows failures inline.

1. A--diff
2. B--related-only
3. C--changedCorrect answer
4. D--watch-only

Why: It uses Git to find changed files.

1. ASeparate module graphs per fileCorrect answer
2. BSeparate machines
3. CDocker containers
4. DNothing

Why: Configurable with isolate.

1. Avitest dash
2. Bvitest --uiCorrect answer
3. Cvitest serve
4. Dvitest open

Why: The UI shows results and module graphs.

1. AtsExpect
2. BexpectTypeOfCorrect answer
3. CtypeCheck()
4. DassertTs

Why: expectTypeOf runs under --typecheck.

1. A--shard=1/3Correct answer
2. B--split 3
3. C--workers 3
4. D--pool 3

Why: Sharding divides files between runs.

1. Acheerio
2. Bhappy-domCorrect answer
3. Cpuppeteer
4. Ddomino-lite

Why: Faster for many tests.

1. Adefault
2. Bbasic
3. CjunitCorrect answer
4. Ddot

Why: XML results.