Skip to main content

Test Strategy Workshop

Deliverable: a written test plan for the capstone that names an opinionated unit / integration / end-to-end split with rationale, and a starter set of tests at each level.

Retrieval Prompts​

  1. Name the three levels of the test pyramid and what each is best at.
  2. State a defensible rough split for a capstone-sized codebase and why.
  3. Explain when an integration test is more valuable than a unit test.
  4. Explain why more E2E tests is often worse than fewer.

Compare and Distinguish​

  • unit test versus integration test (what changes, what stays the same)
  • integration test versus end-to-end test (who drives the system)
  • mock versus fake versus real dependency
  • coverage as a target versus coverage as a floor

Common Mistake Check​

For each statement, identify the error:

  1. "We have 95% coverage, so the code is well tested."
  2. "The service test uses a mocked database, so it is an integration test."
  3. "Every feature needs an end-to-end test."
  4. "Unit tests should mock every collaborator to keep them isolated."

Mini Application​

In one 2-hour session, produce library/raw/test-plan.md in your capstone repo. It must contain:

  1. Split commitment: an opinionated unit / integration / E2E percentage (default 70/25/5 if nothing else applies) with one paragraph of rationale for this capstone.
  2. Unit-level targets: list the 5-10 modules or functions where unit tests will concentrate. Justify each in one sentence.
  3. Integration targets: list every seam in the architecture (DB, external APIs, queues, caches) and decide real/fake/mock for each.
  4. End-to-end targets: list the 2-5 flows that justify E2E coverage. Defend each.
  5. Coverage floors: per-directory floor with exclusions.
  6. CI wiring: a short description of how the suite runs (stages, order, total budget in minutes).
  7. Exit criteria: how you will know the plan is being followed (a weekly audit cadence).

Then write two tests at each level as a starter set, commit them, and confirm CI runs them in the right stages.

Evidence Check​

  • library/raw/test-plan.md committed and reviewed in a 24-hour read-through
  • at least two unit tests, two integration tests, and one E2E test running in CI
  • a coverage report is produced by CI
  • the plan names seams, real/fake choices, and E2E flows specifically, not generically

Stretch​

  • Add one consumer-driven contract test at the riskiest external seam.
  • Configure your unit suite to run in under 30 seconds. If it is slower, identify the slow tests and push them to integration.