Red/Green/Refactor: A pattern for clean code that works, Part I (What, Why)

During my training-oriented pair programming sessions with Martin Salias and Angel ‘Java’ Lopez (don’t miss the chance to read his blog), both extremely experienced and knowledgeable software specialists, the very single thing they focused in teaching me was Test Driven Development. Given the emphasis this software development technique was given in my training, it’s fairly evident that it’s something worth learning. But what is it about?


Test Driven Development, commonly referred to as TDD, is a methodology for developing software, included in the Extreme Programming methodology created by Kent Beck. It focuses mainly on the following cycle:

  • A developer should write tests before actually coding the program functionality.
  • These tests should be carefully written to express the desired features for that solution. In order to check that, it is a good practice to make the test actually fail before writing any code.
  • After making a test, the coding should focus only on making that test pass.
  • Once the test has passed, the code should be refactored; that is, make it cleaner, more understandable, eliminate duplicity, but without altering its public API.
  • Then the new features to be designed must be expressed in another test, and the cycle will begin again.

TDD Diagram

This simple but powerful approach guarantees that the programmer’s concern for the implementation (the how) won’t interfere with his/her concern for the actual features the customer asked for (the what). In fact, even the architecture is subordinated to the functionality, and not the other way round. This leads to a series of benefits, that will be discussed on the following section.


The main benefits developers gain by using TDD are:

  • Less number of defects. Since every single feature is expressed in a test, there is less space for undetected bugs in the final product. It’s very common that after implementing a new feature, another one starts to work improperly. By having a test for each feature, this can be known instantly, since the test for that feature fails.
  • More modularized and extensible code. Due to the methodology implied in TDD, the developers think of the software in terms of small units, and so this leads to smaller, cleaner and more focused classes, that in the end, can be more effectively reused.
  • The features implemented are only those that the customer needs. This is what I believe is the most important benefit of TDD. Since the coding is focused on passing the tests, and the tests clearly express the desired functionality, deviations from the requirements set by the customer are a lot less likely to happen. After all, what is the use of developing unnecessary features that weren’t asked for?

You can check this post by Matt Hawley for some interesting figures about TDD’s advantages and challenges. If you are further interested in this kind of studies, you could check this link.

(Ideas for this section have been taken from ‘Diseño Agil con TDD‘, a must-read free online book for Spanish-speaking developers interested on the subject)

This should cover basically what is TDD, and why it is good to use it. On the second part of this post I’ll speak about how, when and where to use it.

If you disagree with anything I’ve said, you think something can be improved, or you just want to comment on the subject, please don’t hesitate to write a comment here.

Leave a Reply