Test Boundaries and Evidence Selection

Working case

The case service approves a status transition from open to resolved only after a reviewer note is saved. A unit test of the transition rule passes. The HTTP handler, however, writes the status before the note and a database error leaves the case resolved without evidence. A transaction-level test catches this state violation; an API test catches status codes and response shape. A browser task then confirms the reviewer sees a clear result and can retry safely. Each check answers a different question, so a suite of only unit tests cannot replace the others.

Implementation boundary

function mayResolveCase(caseRecord) {
  return caseRecord.status === "open" && caseRecord.reviewNotes.length > 0;
}
console.log(mayResolveCase({ status: "open", reviewNotes: ["Valve checked"] }));
// Output: true

Keep pure rules independent of transport for cheap edge-case coverage. At the transaction boundary, use a real test database with rollback or isolated fixtures so commit behavior is observed. At the API boundary, send an authenticated request and inspect status, body, and stored outcome. Use browser automation for the smallest set of user tasks that can fail through layout, focus, routing, or response handling. A test double can be useful for a remote service, but it should not invent a contract different from the actual integration.

Cost and boundaries

Pure tests run quickly and can cover many combinations; database and browser checks consume more setup and machine time. The right mix is not a fixed pyramid ratio. It follows failure cost and boundary uncertainty. Too many broad browser tests can make a release gate slow and brittle, while too few leave wiring and interaction defects unseen. Record what each test protects and remove redundant checks when another boundary supplies stronger evidence. Keep a small critical path suite fast enough to run on every change.

Failure trace

A handler is refactored to save the note after committing the resolved status. Pure tests still pass because the rule never sees partial writes. A UI snapshot also passes because it mocks a successful response. The defect reaches production and cannot be repaired by a visual comparison. Add a transaction test that injects the note-write failure and asserts the record remains open. Keep the UI check for visible recovery, where it provides evidence the transaction test cannot.

Verification

• Fail the note write and verify the transaction preserves the prior case state.
• Exercise an authenticated API request and inspect both response and stored result.
• Complete one browser task with keyboard and error feedback checks.

Practice drill

List five possible failures in the resolve workflow: invalid transition, missing transaction, wrong HTTP status, stale UI message, and inaccessible error feedback. Assign the cheapest boundary that can actually observe each one. Write one failing test per boundary, then remove duplicate assertions that only mirror internal code. Review the suite after a refactor and ask whether each failure would still turn a test red. That question matters more than aggregate pass count.

Decision note

Select tests by observable risk and boundary, then keep only the repetition that catches a distinct class of defect.

Common Mistakes

• Calling a pure rule test proof of transaction atomicity.
• Mocking the handler response in the only browser journey.
• Counting tests without naming the failure each one can detect.

Connected lessons

Quality and Capacity Engineering; Deterministic Test Doubles and Fault Injection; Accessibility and Visual Regression Checks; Load Tests and Capacity Budgets; Tests across boundaries: assert behavior, not implementation text; Transactions and Concurrent Writes; Browser Journey and Fault-Injection Tests.

Apply and check

Build Project: release evidence and capacity and review Web Development: search and quality contracts quiz.