The Benefits of Test Driven Development

I read these articles about Test Driven Development, This first article is quite short but very succinct and explains the process very simply, which I suppose it is, This is how the article breaks down TDD (Test Driven Development), the article is reviewing a book but does also go through some of the basic tenants of TDD in an easy to understand way

http://www.ddj.com/showArticle.jhtml;jsessionid=4ZJIVDR5CAOCGQSNDLPSKHSCJUNN2JVN?articleID=184416004

1. Red: Write the minimal test code to break your implementation.

2. Green: Write the minimal implementation to pass your tests.

3. Refactor: Clean up any code duplication introduced by the above.

I also found this link to an introductory article on TDD development

http://www.agiledata.org/essays/tdd.html

I have used this system of programming a few times and it certainly has a few advantages. I won't list the advantages here because you can get those by reading one of the two good introductory articles on the process. What I will do is write how I found the process when I used it.

My first point is this is the easiest way to write unit tests or should I say the most painless way to write unit tests for your code.

Writing unit tests is a bit like writing java docs in terms of "things I don't like doing but have to be done". If you are going to write a unit test you have to do it before you write the code, other wise writing the unit test is a real slog of pointlessness. If you write the unit test after you have written the code then you have probably already tested the code using system out's or stepping through the code and seeing what it returns.

The benefits of writing the tests before the code is that you first think about what you are testing, e.g. what should this piece of code being doing. The article states that

"small steps, test first, clean as you go"

This is one of the key points, you write a test and then write some code to pass that test. Then you write another test and get the code to pass that. I have jumped ahead of myself a little bit here, you initially start writing with a failed test. This unusual process often is confuses and annoys people who don't like writing unit tests. The reason for this in my opinion is just to make sure you testing the correct class, you are confirming that this is the code you are going to be testing by putting in some stub code which does nothing and fails the test. Then you write some code to just pass the test you are running,

Although it sounds sad but when you get the green bar and the test passes you do actually feel like you have accomplished something, it's a small win but a win none the less. It is for want of a better word - Progress. Each time your code passes a test you feel like you can see the code improving, gaining functionality.

The benefits of Test Driven Development from my experience are

You write only the code needed to pass the tests and don't waste time writing functionality which isn't used

You write code which is easier to test, which tends to be more modular with low coupling, this code will be easier to reuse in other parts of the software.

The unit tests can be run at any time to test the code is still working

The unit tests can be read by other developers and will help them understand what the code is trying to do

Any refactoring of the code can be run against the tests to make sure it is still working

You have confidence in the code because you know it passes all those tests and works


I don't know if this is really a benefit but once you have tests that you can keep running over and over you can change the code safe in the knowledge that any changes will have to pass the tests you have written. The allows an emergent style of development. I think it is easier to write code, get it to work and then look at the code and see where you can improve it. In the act of writing code to pass certain tests you learn more about what you need to resolve the problem and then you can refine and refactor the solution you have created but with the safety net of the new code having to pass your unit test.

You also benefit from a short iterative steps so if you try something that doesn't work then you haven't lost to much time.

I don't know now if this blog entry is about TDD or just talking about the benefits of unit testing but my advice is too give it ago. I often hear people say they haven't got time to write unit tests but you have to test the code you write anyway but if you do it with system out's or comments you are just testing your code in a none reusable way. I am often surprised by the amount of daft silly bugs I find in my unit tests but when you are just testing a small piece of functionality the mistake is easy to find but if you were testing it at a higher level it might take you a long time to track down the problem.

One of the best reasons I have read to justify why you should write unit tests is

"you know how long it takes to write a unit tests, how long does it take to debug the same piece of code"

by writing a unit tests you are trying to guarantee you won't need to debug that code and if you did need to then you can use the unit test to take away a lot of the possible problems that could occur.

I have written a couple of blog entries on unit testing before if you are interested, they are worth looking at because they will have some links to some more resources like most of my blog entries.

why I like unit testing
http://hoskinator.blogspot.com/2006/04/learning-to-love-junit-and-test-driven.html

about trying to persuade by fellow developer to unit test
http://hoskinator.blogspot.com/2006/05/how-to-persuade-java-developers-to.html

a good link to a journal with some TDD articles
http://hoskinator.blogspot.com/2006/04/test-driven-development-and.html