Learning Test-Driven Development

Preface

Test-driven development is a way of managing fear during programming.

Kent Beck

We are so ineffably lucky! We’ve had test-driven development for years.

Several decades have passed since the developers who wrote the code for the Mercury Space Program practiced Punch Card TDD (test-driven development). XUnit libraries that facilitate the adoption of test-driven development date back to the turn of the century. In fact, Kent Beck, who wrote Test-Driven Development: By Example (Addison-Wesley Professional, 2002) and developed the JUnit framework, refers to himself as having “rediscovered” (and not invented) the practice of TDD. That statement is evidence of his humility, yet it is also the truth. TDD is as old as software development itself.

Then why is it that test-driven development is still far from the standard way to write code? Why is it often the first practice that gets sacrificed when there is schedule pressure, or when IT budgets need to be trimmed, or (my personal favorite) when there is a desire to “increase the velocity of the software-delivery team”? All these reasons are proffered despite the ready availability of empirical and experimental evidence that TDD reduces defect count, creates simpler design, and improves developers’ confidence in their own code.

Why is TDD adopted grudgingly and abandoned readily? The following arguments, heard often from those who are reluctant to practice it, may explain why:

I don’t know where and how to start.

Perhaps the ...