MODULE 06 / 18 · PART 3 · PROVE & HARDEN
Testing & QA
Write the tests that would have caught the bug, not tests that confirm the code runs.
THE SHORT ANSWER
What this module changes.
Coverage is a vanity metric. Ask for the test that fails before the fix and passes after it, plus the boundary values and negative paths that encode what the product must never do.
Ask for the tests that would have caught the bug, not tests that confirm the code works. Coverage is a vanity metric; the tests that encode intent are the ones that matter.
Payment flows, permissions, offline queues and multi-currency totals are the tests that protect revenue and trust. A green suite that only covers the happy path is a false sense of safety.
THE MODULE PROMPT LIBRARY
20 prompts for testing & qa.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Write the tests that would have caught this bug: [bug]. They must fail against the current code and pass after the fix.
Why it worksA test that fails first is a test that proves something.
List the test cases for [function] as a table: input, expected output, and the reason this case matters.
Why it worksForces justification per case instead of a wall of generated assertions.
What are the boundary values and equivalence classes for [function]? Generate one test per class, not per value.
Why it worksSystematic coverage without combinatorial explosion.
Write the property-based tests for [function]: the invariants that must hold for all inputs, and the generators that exercise them.
Why it worksProperties find the inputs you would never think to write.
Design the test doubles for [dependency]: what to fake, what to stub, and where faking would hide a real integration bug.
Why it worksOver-mocking is how green test suites ship broken systems.
Write the integration test for [flow] that exercises the real database and the real serialization, not mocks.
Why it worksIntegration tests catch the contract mismatches unit tests cannot see.
Identify the flaky tests in this suite: [tests]. For each, name the source of nondeterminism and the fix.
Why it worksFlakiness is a bug in the test; naming the source is the only real fix.
What is the test pyramid for this service, and where are we top-heavy? Propose the rebalancing.
Why it worksDiagnoses the shape of the suite, not just its size.
Write the contract tests between [service A] and [service B] so that either side can change independently.
Why it worksContract tests are what make independent deploys safe.
Design the load test for [endpoint]: the traffic shape, the ramp, the pass criteria, and the metrics to watch.
Why it worksA load test without pass criteria is just a stress demo.
Write the test data builders for [domain] so tests read as intent rather than setup noise.
Why it worksReadable tests are tests people maintain instead of delete.
What should this test assert that it currently does not? Here is the test: [test].
Why it worksWeak assertions are the most common reason tests pass while bugs ship.
Write the negative tests for [endpoint]: malformed input, missing auth, oversized payloads, and unexpected content types.
Why it worksNegative paths are where security and reliability bugs live.
Propose the mutation testing run for [module] and tell me which surviving mutants indicate weak tests.
Why it worksMutation testing measures assertion strength, which coverage cannot.
Write the end-to-end test for the critical user journey [journey], and keep it to the smallest number of steps that still proves the journey.
Why it worksE2E tests are expensive; keeping them minimal keeps them alive.
Design the test strategy for [feature] across unit, integration, contract, and E2E. Say what each layer is responsible for.
Why it worksExplicit layer responsibilities prevent duplicated and missing coverage.
Write the regression test for this production incident: [incident]. It must reproduce the exact conditions.
Why it worksIncident regression tests are the highest-value tests you will ever write.
Review this test suite for tests that assert implementation details rather than behavior: [tests]. Propose the behavior-based rewrite.
Why it worksImplementation-coupled tests break on every refactor and teach nothing.
What is untestable in this design, and what is the smallest change that would make it testable?
Why it worksUntestability is a design smell; this turns it into a concrete refactor.
Write the test plan for [release]: what we test, what we deliberately do not, and the residual risk we accept.
Why it worksMakes the accepted risk explicit instead of implicit.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Write one regression test for a recent production bug. Confirm it fails on the old code, then make it pass. Keep it in the suite.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.