Skip to content

Vitest reporter

@brittlehq/vitest-reporter plugs into Vitest’s reporter API. It runs in-process with the test runner, posts per-test results as the suite executes, and reports the final outcome when the run ends.

Terminal window
pnpm add -D @brittlehq/vitest-reporter

Add the reporter to vitest.config.ts:

vitest.config.ts
import { defineConfig } from 'vitest/config';
import BrittleReporter from '@brittlehq/vitest-reporter';
export default defineConfig({
test: {
reporters: [
'default',
new BrittleReporter({
url: process.env.BRITTLE_URL,
token: process.env.BRITTLE_TOKEN,
}),
],
},
});

Note the new. Vitest’s reporter API takes class instances rather than [name, options] tuples like Playwright or Jest. The other framework patterns won’t compile here.

Terminal window
export BRITTLE_URL=https://brittle.your-domain.com
export BRITTLE_TOKEN=brt_svc_xxxxxxxxxxxxxxxx
pnpm exec vitest run

Use vitest run (one-shot) rather than vitest (watch mode); the reporter does fire in watch mode too but each save creates a new Run row.

  • Test result (pass / fail / skipped / todo) and duration.
  • Failure assertion text + stack trace.
  • Test environment name (node / jsdom / happy-dom).
  • The full suite chain (file → describe → test) so the dashboard shows the breadcrumb, not just the leaf.
  • Git commit + branch context, auto-detected.

Nested describe() blocks render as a breadcrumb on the Session Detail page: math › positive numbers › adds two positive numbers.

  • vite.config.ts vs vitest.config.ts. If you have a single shared config, configure the reporter under the test: block. That’s the only place Vitest reads reporters from.
  • In-source tests. Vitest’s in-source test mode ( if (import.meta.vitest)) is supported; the reporter sees them as normal tests with the source file as their location.
  • Worker pool config (pool: 'forks' | 'threads'). Both behave identically. One Run row per vitest run.

Vitest’s reporter accepts every shared option. It has no Vitest-specific options.