Vitest: running JavaScript tests on Vite's own configuration

A modern project already has a build tool, a module resolver and a file transform. A test runner that asks for all of it a second time starts at a disadvantage.

Vitest made the opposite choice: it plugs into the existing configuration and runs the tests with it.

Definition

Vitest is a JavaScript and TypeScript test runner built on Vite. It discovers test files, runs them, compares expected results against obtained ones and hands back a report. ES module modules work natively, with no conversion step.

// billing.test.js
import { describe, it, expect } from "vitest";
import { grossTotal } from "./billing.js";

describe("grossTotal", () => {
  it("applies 20% tax by default", () => {
    expect(grossTotal(19)).toBe(22.8);
  });

  it("accepts another rate", () => {
    expect(grossTotal(100, 0.055)).toBe(105.5);
  });
});

A file whose name contains .test. or .spec. is picked up automatically. The npx vitest command runs it and then keeps watching for changes, replaying only what depends on the file that was touched.

The everyday functions

On the assertion side, toBe compares by identity, toEqual compares content deeply, toThrow expects an Error, and rejects expects a broken promise.

Configuration

A single file is enough to describe the runtime environment and the Code coverage report. It goes at the root of the project, next to the package.json.

// vitest.config.js
import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    environment: "node",
    globals: false,
    coverage: {
      provider: "v8",
      reporter: ["text", "html"],
    },
  },
});

Frequently asked questions

The two interfaces are deliberately very close, to the point where a migration often amounts to changing the imports. Vitest wins on a project already served by Vite, since there is then only one configuration to maintain. On an older base tooled with Webpack, the Jest ecosystem remains deeply established.

While writing, yes: the default mode replays only the tests affected by the modified file, and the feedback loop is measured in tens of milliseconds. In continuous integration you use vitest run, which executes once and then hands back an exit code.

Two conventions coexist: next to the file under test, or in a dedicated folder mirroring the tree. The first keeps the test visible and makes it travel with the code it covers. The second keeps production folders clean. What matters is choosing once, for the whole project.