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. For many people, these concepts sound extreme even today.

The methodology is 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 led to TDD. As the name suggests, in TDD, tests drive the development. This means that the developer writes code only because there is a test that fails. The tests dictate whether the code has to be written, and they also provide a measure when a feature is "done"--it is done 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 that is sufficient to fail, and compilation failures are failures
• You are not allowed to write any more production code that is sufficient to pass the one failing unit test

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 test 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), and a thoroughly tested piece of software.

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

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 IDEs 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 is possible that the feature is already implemented. Either way, you gain insight into your code.

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 IDEs 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 that makes the tests pass. By doing so, you only write code that you actually need and that is the simplest implementation possible. When I say simple, I mean that it should be easy to read, understand, and change. The code should always be easy to understand.

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 that feature.

During the green step, you write 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 should 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.

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.