27 May 2005

Test Driven Development

I’d like to address an unpopular topic Test Driven Development. For some reason most developers don’t like Test Driven Development. One of the main pillars of TDD is the fact that a developer has to develop the test before he even begins to code. I see that many programmers still use a nice client form to test their code, because it is much easier. But you can image that fact that if you don’t have an automated unit test you are not going to test every scenario available every time you alter your code.

 

Another problem I sometimes encounter is the fact that there is no update of the unit test if a bug is found in the code. First thing you must do is reproduce the bug in a unit test and then fix the bug in the code, and not the other way around. This is because we programmers most of the time assume that our change in the in code fixed the bug. If we change code first and then try to write an unit test you might wrongfully assume that the bug is fixed.

 

I’m not saying I like developing unit tests, but I write this item as a reminder to at least myself to why I’m writing these boring test J.

Filed under:

Comments

# Patrick Bes said:

You're right. Unit tests need to be written. But you need to maintain them as well. Not that long ago, I thought I fixed a bug in a method for which there was an Unit Test. When I tested that one method, it worked correctly. So my bug was fixed.

Because the method was in a large assembly, I ran the test for the entire assembly. Again, all lights were green, so I was delighed to have fixed the problem.

But when I ran the application that used the assembly, the bug was not fixed. In fact, a new bug had been created. I was baffled, so decided to get the code for the Nunit test. I was stunned! The code that tested some of the methods that I knew were failing for my application actually did nothing. Sure, they called the methods, but no checks were done to see if the results were correct!

My 2 cents: Use Nunits, but make sure they actually test what the component should do. Don't rely on someone else telling you the NUnit tests are there and correct.

Friday, May 27, 2005 10:47 AM
# Patrick Bes said:

Maintainance of unit test is very important indeed. The fact that the bug that did happend in the application and not in the unit test indicates that the unit test is/was not good enough. The way to go here is try to reproduce the bug in the unittest. In your situation I assume that you added the checks to see if the results are correct.

If all bugs are reproduced in unit tests and then solved. The quality of your unit test keeps growing in a ongoing process.

Friday, May 27, 2005 11:05 AM
# Patrick Bes said:

But that's the difference TDD makes!

When first a test is written for a specific bug (which would have been red before it was fixed, and green after it was fixed) you know you fixed the bug. Of course another bug might occur because you fixed this one, but you write another test for it, before fixing it.

Then indeed, the quality of your tests will increase over time. I think this is the main advantage of TDD, that the quality of your tests is much higher then with unit tests that are written after you've developed the normal functionality!

Monday, May 30, 2005 9:01 AM
# Patrick Bes said:

TDD is a way of life ;) You can not just say I'm creating unit tests while not changing the way you develop software.

To me TDD is a structured way of coding. You get the specs, these specs are the basis for you unit tests. While creating your unit tests and trying to make the tests go green, you create the skeleton/interfaces for your object model. At this point you can see whether the design globally will work or not. You can see it as evidence that your design "works". If all is green, you start implementing the code (calculations, business rules etc etc), and hope everything remains green while doing that.

The main problem with TDD is maintaining the tests. Because in some cases the unit tests contain a lot more code than the code you are trying to test. In the Java world companies like Agitar (http://www.agitar.com/) are specialised in automating the creation of unit tests (by the way they do some cool dynamic an static analysis of the code). So in the beginning of a project the developers are very brave and start with coding their unit tests, but half way a project it becomes "boring" and you see that a lot of unit tests become orphaned.

Monday, May 30, 2005 4:51 PM

Leave a Comment

(required) 
(required) 
(optional)
(required) 
Please add 5 and 8 and type the answer here: