The TDD Spectrum — Understand the culture

Design anything but have a just cause!For practical purposes, very few people who develop software follow the pure vision of TDD, for several reasons. Modern software development usually involves integrating libraries, connecting legacy code, and extending existing functionality.

Many people don’t have the luxury of writing completely new code, so pure TDD isn’t practical in many cases. Instead, many people “doing TDD” sit somewhere on a spectrum that looks something like this:

While each organization has its own set of specific challenges with TDD, the issues we hear about the most from our customers fit into the three basic types above. But within that spectrum, there are many types of TDD practitioners:

TDD Ninjas

On one end of the spectrum are people who are successfully practicing TDD at the “black belt” level. These folks are fully committed to TDD principles and don’t write anything before writing tests — no skeleton, no definitions, no nuthin’ — and are finished as soon as the test passes. As a result, the code is highly efficient and highly maintainable. When we talk to TDD ninjas, they often acknowledge that their success implementing TDD is uneven across teams within their organization.

TDD Pragmatists

The next on the spectrum are people who might design classes, method signatures, etc., and then write tests against those definitions. At the API level, this is equivalent to writing the OpenAPI/Swagger or WSDL definition. We call this the pragmatic approach to TDD.

This approach is a little easier to adopt because it provides more structure and greater clarity. Everything compiles so that a squad can more easily work together. The potential trade-off, however, is that TDD pragmatists may not always achieve the highly-efficient, minimal code design achieved by TDD ninjas.

TDD for Legacy

There are many people who would love to fully commit to TDD, but don’t have the luxury of starting with greenfield code. These folks often create tests to reproduce a defect, or to test expected behavior, in order to change or extend existing functionality based on legacy code.

In our experience, a large segment of those who self-identify as practicing TDD are at or near this point in the spectrum. The logic is that although the test and code are inextricably linked, the test does not necessarily precede the code. Tests do, however, precede the changes to the code.

TDD-ish

On the other end of our spectrum of those who self-identify as TDD are people who test and code in parallel. For TDD-ish practitioners, as long as the test and code are committed and managed together, the development is considered to be driven by testing.

— — — — — — — — — — — — — —

Do share your thoughts..