Skip to main content

Frontend Testing (Vitest)

This page covers how we run and write frontend tests in Refract using Vitest, with conventions that keep UI tests readable and stable.

How it works

Here’s the “shape” of a frontend test in this repo:

1) Vitest is configured in vite.config.ts

The test runner is configured under the test key in apps/portal/vite.config.ts:

2) Test setup is run before each file

apps/portal/src/test/setup.ts currently does cleanup after each test.

3) Follow the existing file + naming conventions

Look at a real example test: apps/portal/src/components/__tests__/textInput.spec.tsx It uses:
  • @testing-library/react
  • Vitest (describe, it, expect, vi)

Extending this system

Use this recipe to add a new Vitest spec without breaking the conventions.
  1. Create a new spec file under __tests__/ next to the code under test.
Example naming pattern: apps/portal/src/components/__tests__/myComponent.spec.tsx
  1. Write assertions using Testing Library queries:
Example:
  1. If you test server data, use Apollo mocks (via existing project patterns) rather than real network calls.
  2. Verify:

What not to do

These rules prevent flaky or undiscoverable tests. ❌ Never run tests on the host with vitest directly. ❌ Never place tests outside __tests__/. ❌ Never let tests silently pass without checking the UI outcome you care about.

File conventions

Use these conventions so new specs stay easy to find. Prefer:
  • one responsibility per test file
  • descriptive describe / it strings that match user behavior

What’s next?

If your new behavior is a form submission, read the error-handling and forms docs next. If you’re writing tests because a new UI feature just landed, wire it through forms + error UX next.