Skip to content

Testing

Test Types

This repository uses two primary test layers:

  • unit tests under src/**/*.test.ts
  • functional/API tests under tests/**/*.test.ts

Unit tests should focus on business behavior with mocked infrastructure dependencies. Functional tests exercise route contracts and integration behavior more directly.

Commands

Fast local feedback:

pnpm test:unit

Full test run:

pnpm test

Functional tests only:

pnpm test:functional

Coverage:

pnpm test:coverage

Unit Tests

Unit tests are configured through vitest.config.mts.

Key points:

  • globals: true
  • Node test environment
  • includes src/**/*.test.ts
  • loads tests/helpers/load-test-environment.ts

Unit tests should prefer mocked dependencies and avoid hitting real infrastructure unless the test is explicitly integration-oriented.

Functional Tests

Functional tests are configured through vitest.functional.config.mts.

Key points:

  • includes tests/**/*.test.ts
  • uses fileParallelism: false
  • runs in forks
  • loads both environment setup and functional test setup helpers

tests/helpers/setup-functional-tests.ts resets the database before tests and applies Prisma migrations using the active DATABASE_URL.

Test Environment

Functional and Vitest flows rely on .env.test.

Important expectations:

  • DATABASE_URL must be set for functional tests
  • the test database schema is dropped and recreated
  • Prisma migrations are deployed before the test suite runs

If you care about preserving local test data, do not point .env.test at a shared or valuable database.

Local Setup For Functional Tests

Typical flow:

pnpm docker:test:up
pnpm test:functional
pnpm docker:test:down

For focused route tests, there is also a lightweight app bootstrap in tests/helpers/make-test-app.ts.

Coverage Notes

Coverage is generated from the base Vitest config and writes to coverage/.

The current coverage setup excludes:

  • test files
  • __tests__ folders
  • declaration files
  • type-only folders
  • some interface/barrel files

That keeps coverage focused on executable application logic rather than boilerplate or contract definitions.

Testing Expectations

When adding or changing code:

  • add unit tests for business logic changes
  • add functional tests when request/response contracts change
  • keep test data explicit and easy to understand
  • prefer deterministic assertions over implementation-detail assertions