Choose what a test proves

A test is useful when it can fail for a meaningful reason. Begin with a behavior that would hurt a user or developer if it broke.

Use small unit tests for deterministic logic, integration tests where real components meet, and browser tests for a few critical user journeys. The labels matter less than knowing which boundary each test crosses and which failure it can diagnose.

Start with a sentence: “Given this state, when this action happens, then this observable result follows.” The last part is the test’s oracle: the evidence that tells you whether the behavior is correct. If the oracle only checks that no exception was thrown, a route could return the wrong book and the test would still pass.

For example, the risk “a duplicate ISBN replaces an existing book” crosses the database boundary. A repository integration test using the real uniqueness constraint is stronger than a unit test that teaches a fake repository to reject duplicates. The risk “the title is trimmed” belongs in a fast unit test. The risk “a reader can add a book from the page” deserves one browser test because labels, JavaScript, HTTP, and persistence must cooperate.

Choosing too low a boundary creates false confidence: the pieces pass while their wiring is broken. Choosing too high a boundary creates vague, slow failures: a browser test says “Add book failed” without identifying whether validation or storage caused it. Use the cheapest boundary that can actually expose the risk, then add a broader test only when integration itself is part of the risk.

List five risks in the Books API. For each one, write the observable failure, the boundary that must be real, and the cheapest test level that can prove it. If you cannot name the evidence, the test idea is still too vague.