Testing philosophy

The shared definition of "good test" that every skill in this set which proposes or reviews tests leans on. It distils Kent Dodds' testing writing and generalizes it past his JS/React context to any language and any layer.

The one principle

The more your tests resemble the way your software is used, the more confidence they can give you. (Kent C. Dodds)

Every rule below is a corollary. The principle is already language- and layer-agnostic; "the way your software is used" just resolves to a different surface in each context. When a testing decision is unclear, return to this sentence.

Pillar 1: Behavior over implementation details

An implementation detail is anything "users of your code will not typically use, see, or even know about." A test bound to one fails in both directions at once:

• False negative on refactor: you change internals without changing behavior, and the test breaks anyway. It cries wolf.
• False positive on breakage: you break the actual behavior, and the test stays green because it was watching the mechanism, not the result.

Dodds' framing: a test that drives your code differently from how real users drive it becomes a third user you never wanted, now you keep the end user, the calling developer, and the test happy.