Skip to content

Testing

No tests exist.

  • No test framework (Vitest / Jest / Mocha / Playwright / Cypress) in dependencies or devDependencies
  • No *.test.ts(x) / *.spec.ts(x) files
  • No __tests__/, test/, e2e/ directories
  • No npm run test script (only dev, build, build:dev, lint, preview)

What does exist (quality gates)

  • npm run lint runs ESLint 9 (with eslint-plugin-react-hooks, eslint-plugin-react-refresh, typescript-eslint)
  • TypeScript itself acts as a type checker, but there's no tsc --noEmit script in CI to gate on type errors (so a type error doesn't fail a build until someone manually runs tsc)

What an initial test suite should cover

Priority order, given this is an internal tool with low test investment historically:

1. Auth flow (highest priority)

Why: login + token storage + protected-route redirect is the foundation. If broken, every other test is moot.

Tests: - Login form submits, token is stored, navigation goes to /accounts - Without a token, visiting /accounts redirects to /login - Logout clears the token and redirects to /login - A 401 from any API call (when added) triggers logout

Tooling: Vitest + @testing-library/react + msw to mock the API.

2. Component sanity tests

Why: shadcn primitives are already tested (Radix UI has its own suite). What's worth testing is project-specific composition:

Tests: - <Sidebar> renders all nav items; nav items match the routes that are mounted - <AppLayout> shows the sidebar + main area - <ProtectedRoute> shows a skeleton while loading, then redirects/renders correctly

3. API client tests

Why: api.ts's request() is the chokepoint. It handles auth headers, error toasts, response parsing. Worth testing.

Tests: - request() attaches Token header when present - request() attaches Apptype header - request() doesn't set Content-Type for multipart/form-data - 4xx / 5xx responses throw with the expected message - (after fix) 401 triggers logout

4. Page-level smoke tests

Why: catches regressions when a page's data shape changes.

Tests: - For each page, render with a mocked successful API response, assert the page doesn't crash - For each page, render with a mocked failed API response, assert the error UI shows

5. E2E

Why: catches regressions that unit tests can't (real browser, real network).

Tests: - Playwright spec: log in → navigate to Accounts → see a list → click into an account → edit → save → verify

Effort: ~1 engineer-week to set up Vitest + msw + 20-30 unit tests; ~1 engineer-week for Playwright + 5-10 E2E specs.

Code coverage

If tests are added, target ≥60% line coverage as a starting CI gate. (Don't enforce >80% on a young suite — that creates pressure to write low-value tests.)

CI integration

When tests exist, the CI workflow (today absent — see build-and-deploy.md) should:

  1. npm ci
  2. npm run lint — fail on errors
  3. tsc --noEmit — fail on type errors
  4. npm run test:unit — fail on failures; report coverage
  5. npm run test:e2e (PR / nightly) — fail on failures
  6. npm run build — fail on build errors

Cross-component status

No FE in the platform has tests at audit time. This repo follows the pattern. As the platform's youngest UI, this is the cheapest place to pilot a test infrastructure — patterns proven here can later be lifted into someli-platform and Someli-Designer if useful.