CHAPTER 09 / 13 · READ → DECIDE → BUILD

Replace confidence with evidence.

Write checks that could catch the defects you care about.

22 min + practiceA risk-based verification reportJump to practice ↓

Start with the rule that would hurt to break

For TaskTogether, write tests for one successful claim, a competing claim, a signed-out request, and refresh persistence. Small pure functions can have unit tests. Permission and transaction behavior need integration checks at the actual enforcement boundary. One end-to-end test should walk the critical user journey. Avoid a large suite that mostly checks its own mocks while never touching the important rule.

Make a bug fail before fixing it

When you find duplicate claims, preserve a minimal reproduction. Ask the agent to write a regression test that fails for that reason, then make the smallest fix. Inspect the assertion: does it check the actual stored state, or just a mocked response? A good regression test should have failed before the correction. Do not weaken the expected result merely to make the suite pass.

Report four states honestly

Use passed, failed, skipped, and unverified. A test you could not run is not a pass. Record the environment and relevant version so results can be interpreted. For browser tests, use meaningful locators and wait for observable state instead of fixed sleeps. Keep fixtures isolated and clean up your own synthetic records. If an intermittent failure remains, collect evidence rather than hiding it behind unlimited retries.

SEE THE DIFFERENCE

A small example. A better decision.

THE INITIAL APPROACH

The test passes because the mocked claim function returns true.

THE MORE USEFUL APPROACH

Two synthetic users submit overlapping claims. Inspect storage and assert exactly one owner exists; assert the other request receives the documented conflict.

The revised test checks the real invariant at the boundary where a race can occur.

Your build steps

Map each major risk to an appropriate test level.
Add a regression test for the one-claim invariant.
Run one complete browser journey and inspect persisted state.
Write a verification report distinguishing passed, failed, skipped, and unverified checks.

FROM THE PROMPT LIBRARY

A useful brief for this step.

Build a risk-based test plan ↗Focuses verification on failures that matter to users.Write a regression test from a bug ↗Ensures a fix addresses the failure that actually occurred.Debug with competing hypotheses ↗Replaces random edits with evidence-driven investigation.All testing & debugging prompts

MAKE THE CALL

Think like the reviewer.

A test was skipped because the database was unavailable. How should it appear in a release report?Skipped, with the limitation and required follow-up stated.Passed, because no assertion failed.Remove it from the report.

BUILD YOUR WORKBOOK

A risk-based verification report

0/3 notes ready

Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.

1. Risk-to-test mapAdd a specific note of at least 20 characters.2. Regression evidenceAdd a specific note of at least 20 characters.3. Verification reportAdd a specific note of at least 20 characters.

Before moving on

At least one check targets the actual data or permission boundary.I recorded what the checks proved and what they did not.I did not mark an unrun test as passed.

Loading your workbook…