Why Teams Struggle With TDD
TDD is simple to describe but easy to practice poorly, and a team that follows the mechanics without the underlying intent often ends up with a large, slow, brittle test suite that actively resists change rather than enabling it. The most damaging pitfalls share a common root cause: tests that couple too tightly to how code is implemented rather than what it is supposed to do, so that any legitimate internal change breaks dozens of tests for no behavioral reason, training the team to see tests as an obstacle rather than a safety net.
Cricket analogy: A team that drills fielding purely by memorizing exact foot positions rather than reacting to the ball ends up rigid and unable to adapt to a real, unpredictable shot, just as tests coupled to implementation details break on any legitimate internal change.
Pitfall: Testing Implementation Details Instead of Behavior
A test that asserts a private helper method was called exactly twice, or that internal fields hold specific intermediate values, is coupled to how the code currently works rather than what it produces. When you refactor — say, merging two helper methods into one — this kind of test fails even though the observable behavior of the public function is completely unchanged, forcing you to rewrite tests as a tax on every refactor rather than benefiting from their protection. The fix is to assert on inputs and outputs of the public interface, treating the internals as a black box.
Cricket analogy: A selector who judges a bowler purely by their exact run-up step count rather than wickets taken and economy rate would penalize a bowler for legitimately shortening their run-up, mirroring tests that fail on harmless internal changes.
// BRITTLE: coupled to implementation details
@Test
void brittleTest() {
OrderProcessor processor = spy(new OrderProcessor());
processor.checkout(cart);
verify(processor, times(1)).calculateTax(cart); // breaks if internals change
verify(processor, times(1)).applyDiscount(cart); // breaks if merged/reordered
}
// ROBUST: asserts on observable behavior only
@Test
void robustTest() {
Cart cart = new Cart(List.of(new Item("Book", 20.00)));
Receipt receipt = new OrderProcessor().checkout(cart);
assertEquals(21.60, receipt.getTotal()); // survives any internal refactorPitfall: Skipping the Red Step
Under deadline pressure, developers sometimes write the implementation first and add a test afterward that they already know will pass, or write test and code together as one block without running the test in its failing state. This silently forfeits the one guarantee TDD offers: proof that the test is capable of catching a bug. A test that has never been observed failing might be asserting on the wrong variable, comparing against the wrong expected value, or not actually executing the code path it claims to — mistakes that only surface if you deliberately watch it fail first.
Cricket analogy: A team that installs a new stump-mic system and only checks it during a live broadcast, never during a pre-match test, risks discovering during the match that it was never actually connected, mirroring a test never observed failing.
A test written after the implementation and never observed failing is a plausible-looking placebo. Temporarily break the implementation (comment out a line, flip a condition) to confirm the test actually turns red before trusting it.
Pitfall: Overmocking and Brittle Test Suites
Mocking is a legitimate tool for isolating a unit from slow or unreliable dependencies like a network call or database, but overuse — mocking objects your own code owns, or mocking so deeply that a test verifies a chain of internal calls rather than real behavior — produces tests that pass even when the feature is broken and fail even when the feature works, because they are really testing the mock setup rather than the system. A practical guideline is to mock only true external boundaries (third-party APIs, I/O, the system clock) and let internal collaborators run for real inside a unit or component test.
Cricket analogy: A batting simulator that lets a player practice against a machine set to always bowl the exact same predictable ball builds false confidence that won't survive a real bowler's variation, mirroring how overmocked tests give false confidence about real behavior.
A good heuristic: if a test's mock setup is longer and more complex than the assertion it enables, the test is probably verifying the mock configuration rather than the system's actual behavior.
- Tests coupled to implementation details break on legitimate refactors, turning tests into a maintenance tax.
- Assert on the observable inputs and outputs of a public interface, not on internal call counts or private state.
- Skipping the red step means a test's ability to actually catch a bug is never verified.
- Deliberately break the implementation once to confirm a new test turns red before trusting it.
- Overmocking, especially of code your own team owns, produces tests that don't reflect real behavior.
- Reserve mocks for true external boundaries: third-party APIs, databases, the system clock, network calls.
- A mock setup more complex than the assertion it supports is a sign of an unreliable test.
Practice what you learned
1. What is the main problem with a test that verifies a private helper method was called exactly twice?
2. What does skipping the red step forfeit?
3. What is a practical guideline for what to mock in unit tests?
4. What is a sign that a test may be overmocked?
5. How can you confirm a newly written test actually detects a bug?
Was this page helpful?
You May Also Like
Writing Your First Test First
Learn what it means to specify behavior with a failing test before any implementation exists, and how to pick a good starting test case.
Refactoring Safely with Tests
Understand why a solid test suite is what makes structural code changes safe, and how to build one for legacy code that has none.
TDD vs BDD
Compare test-driven and behavior-driven development: what BDD adds on top of TDD, when each fits best, and how their tooling differs.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 40 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics