Test Driven Development

This post belongs to this root post and may be out of context if it is read separately.

The Test Driven Development (TDD) is a software development technique that uses tests to make the design merge using the Red-Green-Refactor cycle.

How could I illustrate this…

Have you ever use a ‘gap filling’ exercise? They are used in grammar and language learning, and they look like this:

Gap filling exercise

In the TDD cycle, every new functionality starts writing a test. Such test defines a part of this new functionality in a brief and concise way, and it must fail, as the functionality does not exist yet. Just like in the example below, in which there is a list of sentences that do not work, because they miss some words, but they already suggest how they will look like when they are completed. Here, our test is Red:

Test fails, but functionality is defined

The next step consists in writing the minimum code needed to make the test pass. It doesn’t need to be a perfect code, just make the test pass. We write it fast, like when we write a draft. Even if the sheet is stained with scribbles, the sentences work and could be used in a conversation. We say that our test is now Green:

Test passes but code is not maintainable

Then, we come back to the written code, and clean it up. We erase the scribbles, sharpen the pencil, and re-write the words carefully, to make them readable. We may also re-organize the sentence structure if we thing this will show its intention better. This process is called Refactor:

Test passes and is maintainable

Then, we write a new test, starting the cycle again to continue building our new functionality.

The tests’ scope must be as narrow as possible. Imagine a functionality like if it was a story or an article you are writing. Probably, you have a general idea about the plot, but at an implementation level, you don’t know and you do not need to know how it will be. Instead, you start writing sentences and cleaning up while putting them together. And it is this way, little by little, how your bunch of sentences become a story.

As a result of this approach, we will obtain a minimalistic code that solves specific problems.

Besides, writing the test before writing the code assures us that all the logic is tested. We call this ‘reliable test harness‘. With a reliable test harness, we can modify the code safely, and check quickly whether our last change broke something.

TDD changes our way of building to a more organic and iterative model, trough which we get high quality code that can be modified safely.

Go back to the root post to read about other Agile techniques.


Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑