Johnny Halife’s Blog

Today I was asked how familiar I was with TDD and what was my opinion about it. Since I never posted about this I will do so! Later I will post about things like Scrum and TDD using Microsoft Visual Studio Team Edition

Test Driven Development

So What is Test Driven Development? To answer this question I would like to quote Kent Beck. In his book TDD : By example (Addison Wesley Professional, 2003)

“Test Driven Development is defined under the following rules:

• Never write a single line of code unless you have a fallen automation test.
• Eliminate duplication”

The first rule is really clear, it’s means that you must have an Automation Test written before writing any code line. That is because TDD maps a requirement as a test. I think this really straight forward, if you don’t have a test (requirement) why bother? there’s no need to implement write any code. This rule empowers developers to be pragmatic and focused on the solution scope.

The second one states that no code should be duplicated, because code duplication leads to bad software design.  This rule is derived from Extreme Programming where it’s called “Once and Only Once”.

I would like to make clear that it is wrong to think that TDD is about unit testing alone. There’s another kind of test called a Customer Test. Some authors call them functional tests or acceptance tests. These kinds of tests are used to understand and establish functional requirements and customer experience. They try to express what the customer needs and wants. This kind of test is usually implemented with what is called navigation story boards.

KIS (Keep It Simple)

TDD suggests writing the minimal amount of code needed to successfully run a test and nothing else. That means you should only satisfy current requirements. Although this may seem obvious to a lot of people, this is usually not so. Most developers often write code to cope with requirements that they think might pop up in the future and by doing so they add code that is not needed at the moment. TDD is strongly against this kind of behavior; remember TDD is to keeping the project on scope.

Many people ask me, how to recognize if the are writing good TDD code? One alternative may be looking at the following checklist:

• Is the code appropriate for the intended audience?
• Is the code passing all the tests.
• Is the code communicating everything it needs to (Remember no more & no less)
• Is the code written in the simplest way (I strongly recommend you to read Steve’s McConnell Code Complete 2^nd Edtion).

Refactoring is the key

I suggest you to follow these steps when writing tests, as guide for good TDD practices:

1. Write the test code
2. Compile the test code (If you are following the list, it  will failed because you haven’t implemented the actual code)
3. Only write just enough code to compile.
4. Run the test and see it fail.
5. Implement just enough to pass the test
6. Re run the tests and see them pass.
7. Refactor for clarity and to eliminate duplication (Remember the 2^nd rule!).
8. Repeat this until your code looks as simple as it can.

When you are finished implementing the code you’ll be able to test future changes on the program. There should be minimal usage of the debugger because the steps are so small that you should know which change was the one that caused the tests to fail.

“Working in small, verifiable steps increase your speed in moving forward because you will be moving with more confidence; the confidence is the result of feedback that running the tests provides your” (Extract from TDD in Microsoft.net, Newkirk & Voronstov, MS Press, 2004).

Summary

TDD is about keeping the code as small as you can (by avoiding the things that you don’t need right now and avoiding duplication with refactoring).