A hobbyist' digital garden

Chapter 5 - Test Driven Development

2 min read

Xtreme Programming Wave & Introduction to TDD

The author begins by recounting his first encounter with TDD, introduced by Kent Beck. Before adopting TDD, he used to code for hours before checking for compilation errors or running tests. TDD changed his approach, enforcing small, incremental steps in coding.

The Three Laws of TDD

TDD operates under three fundamental rules that enforce rapid feedback loops (~30 seconds long):

  1. You are not allowed to write any production code until you have first written a failing unit test.
  2. You are not allowed to write more of a unit test than is sufficient to fail (compilation errors count as failing).
  3. You are not allowed to write more production code than is sufficient to pass the currently failing unit test.

By following these laws, a developer is continuously locked into a cycle of writing tests and immediately implementing just enough code to make them pass.

The Litany of Benefits of TDD

  • Certainty

  • TDD ensures you write dozens of tests daily, hundreds weekly, and thousands yearly.

  • The QA process is simplified to a single command: go test ./...

  • Defect Injection Rate

  • While the app itself might not be mission-critical, TDD significantly reduces defects (by 2x, 5x, or even 10x).

  • Shipping based purely on passing tests becomes viable.

  • Courage

  • Why do developers avoid fixing bad code? Fear of breaking something.

  • TDD provides confidence—if tests pass, you know the system still works after refactoring.

  • Documentation

  • Every unit test documents expected behavior.

  • Well-written tests serve as living documentation for how the system should function.

  • Design

  • Writing tests first naturally leads to better software design.

  • Tightly coupled, hard-to-test code forces you to refactor into modular, testable components.

  • Functions that call multiple layers of dependencies become obvious design flaws under TDD.

What TDD Is Not

  • TDD is not a magic formula that guarantees perfect code.
  • Bad tests lead to bad code, just as bad code leads to bad tests.
  • Some rare cases exist where TDD may do more harm than good, and a professional should know when to adapt or abandon it.

TDD is a powerful discipline that enforces certainty, confidence, and better design. However, it is not a silver bullet, and developers must use it wisely. True professionals understand when to follow and when to break the rules in pursuit of high-quality software.

Graph View