Understanding TDD

Now that we have seen what unit tests are and how they can help in development, we are going to learn about TDD.

In 1996, Kent Beck introduced a new software development methodology called Extreme Programming. The word "extreme" indicates that the concepts behind Extreme Programming are totally different from the concepts used in software development back then. It was based on 12 rules or practices.

One of the rules states that developers have to write unit tests, and all parts of the software have to be thoroughly tested. All tests have to pass before the software (or a new feature) can be released to customers. The tests should be written before the production code that they test.

This so called Test-First Programming leads to Test-Driven Development. As the name suggests, in TDD, tests drive development. This means that the developer writes code only because there is a test that fails. The tests dictate whether code has to be written, and they also provide a measure when a feature is implemented: it is implemented when all tests for this feature pass.

Robert C. Martin (known as Uncle Bob) has come up with three simple rules for TDD:

• You are not allowed to write any production code unless it is to pass a failing unit test
• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures
• You are not allowed to write any more production code than is sufficient to pass the one failing unit test

For more information, visit http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd.

These rules sound kind of silly because when you start with a feature that uses a new class or method that is not declared yet, the test will fail immediately, and you have to add some code just to be able to finish writing the test. But by following these rules, you will only write code that is actually needed to implement the features. And you will only write testing code that is needed as well. All the code you write will either end up being part of the final product or it will be a part of your test suite.

Because of the focus on just one feature at a time, you will have a working piece of software almost all the time. So, when your boss enters your office and asks you for a demonstration of the current status of the project, you are only a few minutes away from a presentable (that is, compiling), thoroughly tested piece of software.

The TDD workflow – red, green, and refactor

The normal workflow of TDD comprises three steps: the red, green, and the refactor steps, respectively. The following sections describe these steps in detail.

Red

You start by writing a failing test. It needs to test a required feature of the software product that is not already implemented or an edge case that you want to make sure is covered. The name "red" comes from the way most test frameworks indicate a failing test. Xcode uses a red diamond with a white x on it.

It is very important that the test you write in this step initially fails. Otherwise, you can't ensure that the test works and really tests the feature that you want to implement. It could be that you have written a test that always passes and is, therefore, useless. Or, it may be possible that the feature is already implemented.

Green

In the green step, you write the simplest code that makes the test pass. It doesn't matter whether the code you write is good and clean. The code can also be silly and even wrong. It is enough when all the tests pass. The name "green" refers to how most test frameworks indicate a passing test. Xcode uses a green diamond with a white check mark.

It is very important that you try to write the simplest code to make the tests pass. By doing so, you only write code that you actually need and one with the easiest possible implementation. When I say simple, this means that it should be easy to read, understand, and change.

Often the simplest implementation will not be enough for the feature you try to implement but still enough to make all the tests pass. This just means that you need another failing test to further drive the development of the feature.

Refactor

During the green step, you wrote just enough code to make all the tests pass again. As I just mentioned, it doesn't matter what the code looks like in the green step. In the refactor step, you will improve the code. You remove duplication, extract common values, and so on. Do what is needed to make the code as good as possible. The tests help you to not break already implemented features while refactoring.

Tip

Don't skip this step. Always try to think how you can improve the code after you have implemented a feature. Doing so helps to keep the code clean and maintainable. This ensures that it is always in good shape.

As you have written only a few lines of code since the last refactor step, the changes needed to make the code clean shouldn't take much time.