Jeremy Neander

Quick and Dirty TDD

What is TDD?

TDD (Test-Driven Development) is the an approach to software development which allows for the production of clean and thoroughly-tested code. In practice, it reduces or altogether eliminates the waste and risk associated with debugging and breaking/repairing of code that goes along with other approaches.

The Three Phases

TDD consists of a repeated cycle of three linked steps:

Performing each step supplies the conditions needed for the following step. The result of each cycle is a new element of code, be it a class, method, or other such component, which has a passing test confirming that all functionality performs as expected and/or required.

The Three Rules

In his post on the subject, Uncle Bob discusses some of the many advantages to TDD. He focuses on outlining the three rules which give TDD its structure:

So far, on simple projects with very short requirements lists and simple designs, this process is great practice. As successive projects begin to complicate the design, however, it is becoming increasingly difficult to ensure that the design elements are solid and adaptable as the requirements list grows between iterations. The design must support the process, or the process itself will grind to a halt. But that's a discussion for a future post.

Quick and Dirty Development

Having spent time developing games, I sense some familiarity with the ideas present in TDD. While not directly transposable to or from TDD, the design cycle of "quick and dirty prototyping" has some value to offer.

The process is described exactly as it is titled. It is quick, getting a workable prototype (a test product) up and running as soon as possible. It is dirty, potentially having little regard for design patterns or proven elements, and focused on having something that can be changed and improved. It is also effective, generating a product with each cycle that can then be polished, improved, and optimized (for enjoyability).

It's not difficult to see the translation to the test-driven process:

Developers with no game background might prefer to stick with pure TDD. I find value in both.