Five Ways Test-Driven Development Can Go Wrong

Dave Farley argues that difficulties in test-driven development can signal problems in software design. In this 2021 talk he examines five testing anti-patterns and proposes ways to make feedback more useful.

For Farley, TDD’s value is not just a coverage number: writing tests and code in a short feedback loop can expose coupling, poor separation of concerns and difficult interfaces. These signals still require judgment about the context.

The first anti-pattern, “the liar,” is a test that passes but makes no meaningful assertion. He recalls a coverage target that encouraged tests which executed code without checking useful behavior.

His suggested correction is to remove or improve meaningless tests and observe a new test fail for the intended reason before implementing the behavior. A failing test is useful evidence, though it alone does not guarantee the test is correct.

“Excessive setup” occurs when preparing a test takes a large amount of work. Farley treats this as a prompt to inspect dependencies and separation of concerns, rather than immediately accepting a fragile setup.

He shows a test that starts an entire Jenkins environment to check a URL string. For that particular behavior, a smaller unit-level check may be faster and clearer; broader integration tests can still be appropriate when the interaction itself matters.

“The giant” is a long test with many assertions and unclear intent. Farley says failures can be hard to diagnose when unrelated behaviors are bundled into one case.

He prefers decomposing such cases into focused tests and suggests one assertion per test as a rule of thumb. Multiple related assertions can also be reasonable when they describe one coherent behavior.

“The mockery” relies on so many mocks or stubs that little or no production behavior is exercised. In his example both the car and engine are mocked, leaving a test of the configured doubles rather than their real implementation.

He recommends reconsidering the design and focusing on the behavior the software must provide. Test doubles can be useful at a boundary, but they should not replace the behavior the test is meant to verify.

“The inspector” breaks encapsulation to assert private implementation details. Farley warns that tests coupled to internals may fail after harmless refactoring even when externally observable behavior remains correct.

He shows a method apparently added only for a test and asks whether a better abstraction or dependency boundary would let the test observe behavior without exposing private state. That is a design question, not a prohibition on all test-specific instrumentation.

Across the five patterns, his theme is to use testing friction as feedback: simplify setup, clarify behavior, improve separation and avoid treating coverage as the goal itself.