# Testing

What test suites exist, what they protect, and the rules for adding to them.

## Suites

| Suite | Where | What it covers | State |
|---|---|---|---|
| API integration tests | `raven-test-integration` | Tier 1–3 API coverage against a running server | Green apart from three known server bugs (March 2026). Details in that repo's `CLAUDE.md` |
| E2E | `raven-test\e2e` (separate repo `raven-test`), Cypress 9.7.0 | User workflows in a browser, against remote devtest servers, with version validation and environment-based config | **[unverified]**: last commit 2026-02-22; current pass state unknown |
| Licence verification gate | To be written (`NET10-PORT.md`, section 0) | Every stored v8 licence still verifies | Not started |
| Unit tests | none | — | Roadmap step E |

The old regression and load-test project was disabled as flaky; nothing runs it.

## Critical paths

These must never break. Coverage is checked against this list before refactoring:

1. Authentication and authorization (JWT, roles, 401/403)
2. Customer management
3. Work order creation, status flow, through to invoicing
4. Quotes, PMs and contracts
5. Scheduling
6. Inventory and parts
7. Reports
8. Data lists: filtering, sorting, saved filters, paging
9. Licence verification

## Rules

- **Prove a gate on the unmodified code** before changing anything, so a later failure points at the change, not at the test.
- **Fix or delete a broken test.** Never leave it failing without a recorded reason. A known failure waiting on a server fix is recorded with its case number.
- **Do not test what cannot be seeded.** Tests that need IDs not known at test time (such as warehouse IDs for stock levels) are left out and listed as such.
- **`data-testid` attributes** for anything Cypress selects, so tests do not depend on CSS classes.
- **Fixtures with customer data stay outside the repo**, found through an environment variable.
- New tests go where they protect the most: back-end API first, then browser workflows.