Kent Beck distinguishes test composition from isolation, advocates trimming redundant assertions

Kent Beck clarifies that composition and isolation are different properties of tests, not the same thing. Isolation guarantees that a test's result is independent of other tests, similar to referential transparency in functional programming. Composition means that a suite of tests run together should provide predictive confidence, even when individual tests aren't comprehensive on their own. Treating them as identical leads to redundant test suites where later tests re-assert what earlier tests already cover.

Beck's proposed technique is to trim later tests of assertions already covered by earlier tests in the suite. When test2 copies and extends test1, the assertions from test1 become redundant in test2. Rather than deleting test1, which loses specificity, or leaving both tests as-is, which creates redundancy, Beck recommends simplifying test2 to only assert on the new behavior. The composition of test1 and test2 maintains the same coverage and specificity, and may even improve specificity since test1 can fail while test2 passes.

The practical payoff appears in scenarios with orthogonal dimensions, such as 4 ways of computing interest and 5 ways of reporting it. Brute-force testing requires 20 tests, but composition reduces this to 10: 4 tests for computation, 5 for reporting, and 1 test demonstrating they are wired together. This requires design work to make the dimensions demonstrably orthogonal, but the investment pays off in tests that are faster, more readable, easier to change, more specific, and less sensitive to structure changes.

Beck acknowledges that experienced testing developers often react with shock to the idea of reducing assertions, saying they would never do so. He attributes this reaction to fear rather than principle, arguing that composition isn't making tests worse but making the whole suite better as judged by several valuable properties. The approach requires a shift from evaluating tests individually to evaluating the suite as a system, which demands more design thought but yields more maintainable test code.