Skip to main content

Testing

Audience: developers & AI agents · Scope: how we test the site end-to-end — the standard, the how-to, the reusable test-support API, and a catalog of every spec · Last reviewed: 2026-07-13

TL;DR — We test through a real browser with Playwright (the suite is in tests/README.md). Every feature ships with e2e coverage: drive the real UI, then assert both the persisted state and the observable effect (the intercepted Pipedrive payload, a recorded sync row, the nudge due-set, the page state). Pipedrive is never really called in the everyday suite — writes are captured, and an always-on org-6034 guard blocks any stray write.

The standard — e2e coverage at every feature​

The normative rules live in the e2e test standard — spec grouping, the Actor > Feature titles, the per-test Setup / Action / Checks documentation, the one-row-per-test catalog, and the checklist. In short, when you build or change a feature, add specs that:

  • Drive the real action a user takes (a click, a form submit), in the right project — anon (not logged in) or agent (the automation account). See guide.md.
  • Assert in two places: the persisted state (read it back via the test-support API) and the observable effect — the captured Pipedrive payload, a recorded stage-sync row, the nudge due-set, the rendered page state. One without the other misses half the behaviour.
  • Seed through the app, not SQL (the application-factory pattern), and clean up what you created.
  • Keep Pipedrive / Google Sheets writes off by default (capture mode); gate any real-destination check behind E2E_LIVE_SMOKE=1 / PIPEDRIVE_SEND=1.
  • Reuse the test-support API for state and fixtures instead of hand-writing DB/CLI glue.
  • Name & document it to the standard, and catalog it — one row per test in catalog.md.

This mirrors the Testing section every feature doc must carry (see the feature standard).

The docs​

DocWhat it covers
../standards/testing.mdThe standard (rules): spec grouping, Actor > Feature titles, the per-test Setup / Action / Checks documentation, the one-row-per-test catalog, and the done-when checklist.
guide.mdThe how-to: the local stack (URL, cert, Cookiebot consent), the projects, the test accounts + how to use them, the settings / env vars, common specs & patterns, and how to add a test for a new feature.
support-api.mdThe test-support API — the secret-gated HTTP endpoint + the support client (tests/support/cli.ts): every command and how to add one. Reuse these in new specs.
concepts.mdPlain-language primer: what E2E / capture mode / test doubles / fixtures mean, and the Playwright vocabulary.
catalog.mdEvery existing spec — what it drives, what it asserts, and which feature it covers.
../pipedrive/testing.mdPipedrive-specific: the capture / org-6034 guard in depth, send mode, the live smoke, and the deal-payload test matrix.

Install & run: tests/README.md.