TDD: A Pattern Of Process

I was pondering, the other day, whether TDD stood for Test Driven Development or Test Driven Design. I don’t think the distinction is terribly important, and it might also be that it is a personal choice of philosophy or opinion. Regardless, as I was thinking about this, I ended up grabbing a note book and a pen, and produced the brain dump laid out bellow.

TDD is not a tool of software design, but a pattern of process. Designing is when you precisely describe something before you bring it into existence. Writing a unit test before the production code, can certainly be seen and used as a tool for designing software, but this is not all that TDD is.

Design tools are things like rulers, pencils and unit tests. The process of using a design tool is not itself a tool of designing, but the tools are a constituent part of the process; or rather, their use is.

TDD is a pattern of process, that prescribes the use of unit tests before production code, and continuous refactoring, as design tools. This way, TDD naturally encourages good software designs, but it is not itself a tool or method of designing software.

TDD is a pattern of process. It must be instantiated for every project, for every programmer. The concrete implementation by a person, on a project, is influenced by the context of the project; the tools available, the unit testing frameworks and drivers, the people on the team and their experiences, programming languages, environments, build tools and so on. Even so, the mantra of TDD stay the same; “Red, Green, Refactor.” This mantra is the repetition, the pattern, of the process. This pattern is Test Driven Development.

So there you have it. I call it Test Driven Development, instead of Test Driven Design. I think of TDD not as a process, and not as a design tool, but as a pattern of process.

I think of TDD as something that is composed of smaller parts: writing unit tests, writing production code and refactoring.

I think of TDD as something that defines a strict relationship between its constituent parts: production code must only be written in response to a failing test or as part of a refactoring; refactoring is only allowed when all tests pass; you are not allowed to add new tests when others are failing.

I think of TDD as something that must be composed with other things in order to form a whole; something more complete, practical, useable.

This is my definition of TDD.