Learning to love Junit and Test-driven development

I have been recently starting to use Junit tests in my code. It was after reading some agile and extreme programming articles I wondered it if was actually any good, I read the article below actually just after I had used it for a while

http://www.pragmaticprogrammer.com/articles/stqe-01-2002.pdf


There are many other articles and blogs probably extolling the virtues of unit testing more eloquently than I can but I thought I would put my own experience down in ink. I had been made to write unit tests before and I found them a bit of a pain and not really very useful. This is probably a similar experience to many people. I program in Java so I used Junit. The reason why I didn't get on with unit testing is because firstly we had a great big pile of spaghetti code and writing unit tests for it was proving to be almost impossible. Fans of unit testing will probably be screaming that's what you get if you don't write unit tests.

I also never felt the benefit of writing the tests because I wrote the tests after I had actually written the code, so there wasn't really any benefit because the code I was testing was already working. Of course there would be some benefit if I had to change anything later but overall I found it a hassle.

So after reading a few articles I got inspired a bit and thought I would try it out, the articles I actually read that made me look at how I was working was the craftsman articles by Robert C. Martin

craftsman article link

its a bit odd because they are written in basically a silly way but because it was a story it made it more interesting and more similar to what I was doing at work.

So I decided I would start to code by writing the unit tests whilst I created the code and importantly I would start with a failed test and then do the simplest thing to make the test work. Test-driven development (TDD) as this method of developing is known although sounds like a waste of time it did have some benefits that weren't obvious.

1. it made me think about what the function should do and how you should deal with different scenarios. I had clear objectives e.g. what should this method, class do.
2. Starting simply meant that I could slowly tackle the problem and then build from that and the code would run my earlier tests to see if I had broken it
3. I found that I wondered what should happen if I passed something obviously wrong to the method and then I thought about what should happen and tested for it.
4. I had confidence in the code I had written, I knew that it did what it should do.
5. After you have got it to work, it is easier to refactor the code and tidy it up because you have tests that you can run to check that your refactoring hasn't broken anything.
6. It is morale boasting to see the green line of junit pop up and it stops you getting in the scenario where you are working on lots of bits of a class at once which you don't know if it will work until you plug them all together, which at that time it's hard to find the problem anyway.
7. I would often catch small minor bugs and it was easy to find them as I had basically isolated them.

The final benefit is more of a general benefit. As I was thinking about testing the code I would often make choices on the design of classes and methods so that I could test them. This resulted in my code being far less coupled because to test things independently you need to create decoupled pieces of code.

So far I haven't used this development process on projects or pieces of code that are large or complex but I have certainly felt the benefits of Test driven development and would recommend it to people. Even if you are skeptical it surely worth giving it a try, if you don't find it beneficial don't do it again and you can feel vindicated in your belief testing is no good and if you do find it beneficial then you have benefited and you can spread the word of Test Driven Development. The one piece of advice I will give you is I would try Test Driven Development on some new code you are writing, if you try and add it into a piece of code that already exists you will quickly become disenchantment with the process because of the sheer number of tests you would have to write and writing tests after the code has been written is very arduous and unenjoyable.

As I side project I have decided to try and persuade my fellow workers to try it, I will tell you how it goes.

Hoskinator signing off