Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -106,9 +106,30 @@ The skill is maintained code. A change that breaks it or makes it stale must upd

Never weaken a recipe's assertions to make it pass.

## What to test

Prove a change by using it: `npm run lint`, `npm run typecheck`, `npm run build`, then drive the feature in the real app with `verify-debatelab`. New tests are not a substitute for that, and a test-heavy diff is harder to review.

Write a test only when a regression would be costly or hard to notice by using the app:

- auth, sessions, RLS and pgTAP policies, and cross-user or cross-debate isolation;
- billing, Stripe webhooks, quotas, daily limits, and cost accounting;
- migrations and data integrity, concurrency, and the collaboration service;
- parsers, validators, schemas at a trust boundary, prompt routing in the fake provider, and stream accounting;
- a fixed bug that could plausibly come back.

Do not write tests that:

- restate a TypeScript type or a schema's shape;
- check that a removed feature stays removed, or that a column, file, export, route, or translation key exists (the i18n catalog check already covers keys);
- assert static copy, or only that a component renders;
- only exercise mocks, or can never fail.

Keep a PR's test diff small enough to read next to the change. Deleting a test that cannot catch a real regression is not weakening tests; deleting or loosening one to make a failing run pass is. Never lower a coverage threshold in `vitest.config.ts` without Adam's approval.

## Hard boundaries

- Start bug fixes with a failing test or repeatable browser reproduction when a suitable test layer exists.
- Start bug fixes with a failing test when the bug is in behavior listed under [What to test](#what-to-test), otherwise with a repeatable browser reproduction.
- Stub sessions prove rendering only. Do not call them authenticated backend proof.
- Never put staging or production credentials in jobs, logs, traces, screenshots, commits, comments, or docs. Two scoped exceptions reach jobs only through GitHub Actions secrets:
- the protected staging values;
Expand Down
2 changes: 2 additions & 0 deletions docs/testing.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,8 @@ npx vitest run src/test/security/url-validation.test.ts

For a bug, watch the reproduction fail for the expected reason before implementing the fix.

Which behavior deserves a test, and which tests not to write, is in [AGENTS.md](../AGENTS.md#what-to-test). The short version: test specs where a regression is costly or invisible (auth, RLS, billing, quotas, migrations, concurrency, parsers, regressions of fixed bugs), and prove everything else by using the app.

## Collaboration service tests

```bash
Expand Down
Loading