What my colleagues often say when they hear TDD is :  “It makes no sense”, “We do not need that”, “I am doing without TDD since ten years”.

Indeed, maybe, you do not need it. Indeed, you were doing without it but if you are a developer, you should be open to new technologies, curious and maybe you should test it before saying that you do not need it.

Main bugs come from stupid errors. If you use TDD, a lot of this (syntax, typo, omission) error will emerge quickly.

To make your code testable you have to understand all the methods and objects you use. I think it is the main reason why some developers fear about TDD cause if you want to simulate your httpcontext for example, you have to understand how a httpcontext works.  Also, to do that, you have to “mock”, good tools exist to help developers to setup fake context but It cost you time.

Is it worth? I would say yes. In the end of the process,  you can be self-confident with your code and you can explain to everyone what you are doing without gray area. Moreover, if you change something in your code, you should be able to know if there are side effects or not. You will execute all your tests and if all your tests pass, you are safe. If not, you can immediately know where you have to change.

The other great thing with TDD is the iterative way. You create a test, it fails, you write some code, you execute the test, if it is ok, you write a new test,… Like this you feel less overwhelmed by your project.

The definition from Wikipedia :

Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration’s tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”. Bob Martin

I guess it is what a developer should understand. Writing a test is not only test but it a act of design.

For example, we have an application who manage flights in the Airport X. And the client want to see all the flight details who land between 3 PM and 4 PM in that Airport. The questions are : What do you need ? Where do I have to query the data ? Also, maybe you have to deal with 5 or 6 web services.  How are you going to test this function without unit tests ?  Are you going to create a gridview to see the results and go in debug mode ? It is going to be a nightmare. But if you go step by step by using TDD, I am sure it will be easier cause when you will write your tests, you will ask the right questions and you will better understand the domain you are dealing with. It is, “Think before programming”.

In conclusion, I am not going to explain how TDD is working. I know some websites explain that better than me. I will give you some links that I’ve found usefull during my learning process.  Also, maybe my opinion on TDD will change, in that case, I will update this post. As usual, feeback is welcome.

Related Links :

Wikipedia

AgileData

Rob Connery

Phil Haack

NOTE : For my unit tests, I am using Visual Studio 2008 SP1. I used Nunit in the past but, for me, VS makes a good job with unit test so I’ve switched. If you have feedback in that topic, you’re welcome.

NOTE2 : TDD without Mocking is not TDD, I will write a post about that in the future.

Filed under: Agile on May 27th, 2009