Behavioral Tests

Tests should be sensitive to the behavior a caller can observe: they specify the contract, not the implementation. “The more your tests resemble the way your software is used, the more confidence they can give you” (Dodds); Khorikov’s unit of behavior is the same idea given a noun.

This is one half of a pair the literature keeps distinct: sensitive to behavior (this note) and insensitive to structure (its mirror). Beck listed them as two properties, and Bache’s 2.0 keeps them apart too: “Sensitive to Behaviour” under “Predict Success in Production,” “Insensitive to Code Structure” under “Minimize Total Cost of Ownership.” A test can honor one and violate the other, so this list keeps them separate.

Behavioral is also the property most other trade-offs cross: fidelity to real usage is what Fast, Deterministic, Composable, and mock-driven Writable each buy their gains by moving away from. See Desiderata in Tension.

Part of Test Desiderata.

Measuring: mutation score against line coverage (high coverage with a low mutation score flags assertion-free tests), mock density per test, and the test-churn to production-churn ratio.

Sources

• Kent C. Dodds, Testing Implementation Details: “the more your tests resemble the way your software is used, the more confidence they can give you.”
• Vladimir Khorikov, Unit of Behavior: naming and framing tests around the unit of behavior, not the method under test.
• Emily Bache, Test Desiderata 2.0: keeps “Sensitive to Behaviour” and “Insensitive to Code Structure” as two distinct properties, under different macro goals.