Process

In the previous section, we defined TDD, simple design, and refactoring. In this section we define a process that can be used to do TDD. There are two aspects to the process: One aspect is focused at a task or feature level, and the other focuses on an individual test.

Test List

In Kent Beck s book, Test-Driven Development: By Example (Addison-Wesley, 2003), he describes a test list . When starting a new task or feature, you need to brainstorm a list of tests. As you think about these tests, write them down. In addition to describing the requirements unambiguously, this test list also indicates the scope of the activity and is the most complete definition of the completion criteria. How long should you spend doing this? For most tasks that end up taking about 4 hours, we spend about 15 “20 minutes doing this activity. If the scope of the list is too large, the list can be the basis for further estimation.

After the list is complete, you need to choose the first test to implement. The main criterion is that the test you pick should provide useful feedback for the problem that you are solving. As you complete each test, just cross it off the list. When there are no more tests left to implement, you are finished. See Chapter 2, Test-Driven Development in .NET ”By Example for an example of a test list for the implementation of the Stack .

Red/Green/Refactor

Red/Green/Refactor defines the process for implementing each test in the test list. The goal of this process is to work in small, verifiable steps that provide immediate feedback. William Wake, in his book Extreme Programming Explored (Addison-Wesley, 2001), details the programming tasks as follows :

1. Write the test code.

2. Compile the test code.

   (It should fail because you haven t implemented anything yet.)

3. Implement just enough to compile.

4. Run the test and see it fail.

5. Implement just enough to make the test pass.

6. Run the test and see it pass.

7. Refactor for clarity and to eliminate duplication.

8. Repeat from the top.

If followed literally, this process forces you to work in very small steps ” so small that at first you may think that individually they are ridiculous. However, the smaller the step, the easier it is to determine whether you made a mistake. The alternative is to wait until you have made a lot of changes to the code and then run the tests. If something fails after you have made a lot of changes to the code, you don t know which change was the one that caused the failure. In fact, if you can work in really small steps with the tests providing immediate feedback, you can forget about using the debugger; you ll know exactly where to look because the step was so small. Working in small, verifiable steps increases your speed in moving forward because you will be moving with more confidence; this confidence is the result of feedback that running the tests provides you.