Testing Strategy (E2E & Integration)

E2E: reserved for critical/high-stakes flows

Every UI change already gets manually verified in a running browser (a standing global rule) — that catches most regressions during development. Automated E2E tests are for the smaller set of flows where a silent regression later would actually be expensive:

• Authentication (login, signup, logout, password reset)
• Checkout/payment flows
• The core happy path of the product (the thing the product exists to do)

Don't write E2E tests for every feature with UI interaction — that's duplicate coverage of what manual verification already caught, at high maintenance cost (E2E suites are the most expensive tests to keep green).

Integration tests: every API endpoint, no exceptions