Saleem Siddiqui - Learning Test-Driven Development: A Polyglot Guide to Writing Uncluttered Code

• 2021-04-19: First Release
• 2021-04-27: Second Release
• 2021-05-11: Third Release
• 2021-05-11: Fourth Release
• 2021-07-13: Fifth Release
• 2021-08-26: Sixth Release

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

Kent Beck

We are so ineffably lucky! Weve 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. 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 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 tentatively and abandoned readily? The following arguments, heard often from those who are reluctant to practice it, may explain the reasons:

1. I dont know where and how to start. Perhaps the most common reason is lack of awareness and exposure. Like any other skill, writing code in a test-driven style is something that needs to be learned. Many developers either havent had the external inducement (time, resources, guidance, encouragement) or internal motivation (overcoming ones own reluctance and fear) to learn this skill.

2. TDD works in toy programs or during coding interviews, but not when writing real world code. This is untrue yet understandable. Most test-driven development tutorials and booksincluding this oneare constrained to pick relatively simple examples from an obvious domain. Its difficult to write a TDD article or book with actual code from a piece of software plucked from a commercially deployed application (say, from a financial institution, a healthcare management system, or a self-driving automobile). For one thing: much of such real world code is proprietary and is not open-source. For another: its the job of the author to show code from a domain that has the widest appeal to the largest audience. It would be illogical, bordering on obscurantism, to show TDD in the context of a highly specialized problem domain. Doing so would require, before anything else, a lengthy explanation of the arcane jargon and cant of that domain. That would defeat the very purpose of the author: making TDD understandable, approachable, even lovable.

   These obstacles to using real world code in TDD literature notwithstanding, developers regularly write production software using test-driven development. Perhaps the best and most convincing example is the suite of unit tests for the JUnit framework itself. The Linux Kernelpossibly the most strenuously used piece of software in the worldis being improved with unit tests.

3. Writing tests after-the-fact is sufficient, TDD is too restrictive and/or pedantic. This is more refreshing to hear than the occasional rant that unit testing is overrated! Writing tests after writing production code is an improvement over writing no tests at all. Anything that raises the developers confidence in their code, reduces accidental complexity, and provides authentic documentation is a good thing. However, writing unit tests before writing the production code provides a forcing function against creating arbitrarily complexity.

   TDD guides us to simpler design because it provides these two practical rules as guardrails:

   1. Only write production code to fix a failing test.

   2. Refactor energetically when, and only when, tests are green.

Does test-driven development guarantee that all code we ever write will automatically and inevitably be the simplest code that works? No, it does not. No practice, rule, book, or manifesto can do that. Its up to the people who bring these practices to life to ensure that simplicity is achieved and retained.

This books content explains and instructs how test-driven development works in three different programming languages. Its purpose is to instil in developers the habit and self-belief to use TDD as a regular practice. That purpose may be ambitious, but Im hopeful it isnt elusive.