Test Design

Overview

Answers "what input should a test feed, what should it assert, and what should it mock". Does NOT cover the red-green-refactor rhythm (that is TDD).

Core principle: tests protect a behavioral contract that users/callers can observe — not implementation details, and never a coverage number. A good test is a falsifiable spec of the contract; a bad test restates the code in another syntax.

REQUIRED COMPANION: for the write-test-first rhythm, see tdd. For module boundaries when mocks multiply, see solid. This skill only governs the design quality of cases and assertions.

When to Use

• Adding or modifying unit/integration tests for a piece of code
• Reviewing someone's tests to judge whether they are effective or formalistic
• Deciding "is this code worth testing?" or "unit vs integration?"
• About to write a fake test under coverage pressure, deadline crunch, or sunk cost

When NOT to use: just running tests / reading failures → test-runner. Just following the test-first rhythm → tdd.