testing

Testing Strategies and Quality Assurance

Directives for writing and reviewing tests. Use Australian English spelling throughout.

---

Testing Pyramid

• Structure the test suite as a pyramid: many unit tests at the base, fewer integration tests in the middle, few E2E tests at the top.
• Prefer fast, cheap, reliable tests at the bottom; accept slower, more brittle tests only where necessary at the top.

     /\       E2E (few) — slow, expensive, brittle
    /  \
   /____\     Integration (some) — medium speed, more stable
  /      \
 /        \   Unit (many) — fast, cheap, reliable
/__________\

---

Unit Testing

• Test one behaviour per test; avoid testing multiple concerns in a single test.
• Use Arrange–Act–Assert: set up data, perform the action, assert the outcome.
• Mock external dependencies (APIs, databases, file system) to isolate the unit under test.
• Use descriptive test names that state the scenario and expected outcome (e.g. should return null when user is not found).
• Aim for 80–90% coverage of critical paths; avoid chasing 100% for its own sake.
• Keep tests fast; avoid real I/O, sleeps, or heavy setup.

---

Integration Testing

• Test interactions between components, services, or modules.
• Mock external services (third-party APIs, payment gateways) but use real or in-memory databases where appropriate.
• Test database connections, queries, and transactions; use test fixtures and clean up after each run.
• Verify API contracts, request/response shapes, and error handling.
• Prefer bottom-up or sandwich approaches over big-bang integration.

---

End-to-End Testing

• Test complete user flows (e.g. login → create item → checkout).
• Use data-testid attributes for stable selectors; avoid CSS classes or XPath that change with styling.
• Prefer Cypress or Playwright for web E2E; avoid brittle, implementation-coupled selectors.
• Keep E2E suites small and focused on critical paths; they are slow and costly to maintain.
• Run E2E against a dedicated test environment; avoid production data.