2.0 KiB
2.0 KiB
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:
- Authentication and authorization (JWT, roles, 401/403)
- Customer management
- Work order creation, status flow, through to invoicing
- Quotes, PMs and contracts
- Scheduling
- Inventory and parts
- Reports
- Data lists: filtering, sorting, saved filters, paging
- 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-testidattributes 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.