Chaotic Java

Test Driven Development (TDD for short) is a method of software writing taken from eXtreme Programming (XP for short). In its essence, TDD means Test first, Write later. In an earlier post of mine, which related to books I want to buy, Patrick asked me about Test Driven Development (or TDD). In my answer I promised to write more about it, and here we are.

What I write in this post is from my personal experience by leading a team of four people writing a small multi-tier application in dotNet, using the TDD method for development of all the server tiers (the application tiers were eventually not developed by us). We used Visual Studio 2005′s integrated NUnit, but obviously JUnit and TestNG integrations for Java IDEs are encouraged to be used for Java development. The post itself is not about how TDD works, though.

At first glance, TDD is not intimidating, it’s just weird. Testing a method before it was even written can be more than just confusing to most. And implementing it only to answer to a specific set of tests, that is even weirder. The idea behind it is a simple one: Before you rush to writing the most generic of methods and classes, write the tests that correspond to your set of goals brought to you by the software design papers, and only then begin implementing the methods and classes so that all the tests pass.

The more subtle advantage is that by doing that, you actually work around a very known problem in code quality assurance where the writer of a piece of code can’t be the one writing the tests for his own code, because he’s biased about it – “Black box” tests are always preferable. By writing the tests beforehand, you get an advantage by doing the opposite – You write the code so it would specifically make the tests pass, and by doing that you write code that does exactly what the design papers ask for, nothing less and probably not a lot more.

I found that the hardest part was the assimilation phase. You get experienced software developers and designers which never before experienced TDD and you need to convince them that not only writing tests before hand doesn’t waste precious time, it actually saves time on the long run.

The best convincing point is that TDD creates a safety net – By writing tests beforehand, you never actually forget to test anything so that changing code in mid-development always leaves you calm that your code is always working as long as the tests are green. Of course, before every code change, you will write a test to make sure it works – The test would fail, and only then the code change will occur. This assures the safety net tighter and tighter all the time.

The second problem I was faced with is hoping that the people would write enough tests. Also, it’s very important that all team members implement TDD. The advantage with TDD is that it offers a safety net and a quicker way to develop exactly what’s on the goal list through the entire project – If not done even by one developer, TDD loses a lot of its effectiveness. Luck was on my side, and I think that with better planning it could actually be a part of the training before using TDD: The team started making completitions of who writes the more tests in various conditions – Absolute numbers, per method, etc.

The surprising advantage we got from using TDD is code coverage. Sometimes, unused code was found, and sometimes it revealed untested areas, which when tested yielded errors and saved hours of debugging in frustration when things start to fail. Every framework I know today supploes code coverage, and it’s very handy and should be turned on (if turned off by default) and used frequently. Also, this could be another measurement for competition – Which programmer reaches the highest code coverage for an amount of code lines, etc.

So, for a short conclusion, these are my thoughts on TDD implementation in a project:

• Introduction is extremely important. The developers need to know why they should switch their way of writing code, and how it can actually save development time rather than increase it.
• Instructions on how to actually implement TDD are extremely important as well. The developer has to know exactly what to test and how – Which basically means everything and very thoroughly.
• The testing frameworks should be convenient for use and well integrated into the IDE. If your code repository allows for it, make it alert when code has been checked in which breaks any of the tests, as well.
• Code coverage is very useful and should be used at all times, both to reveal unused code and to reveal untested code.
• Competitions or games can be implemented and encouraged in order to increase the fun factor in writing tests, which are always a nuisance for developers. If the work place allows it, types of gifts could be even handed out to those who win in those competitions constantly.
• Make sure it happens by working with the developers, sitting by them and see where they are writing tests and where they miss out – TDD is confusing and weird at first, and it needs careful attention from a team leader who’s trying to assimilate it into his team.

I hope I answered Patrick’s questions and helped a bit to some. Also, if others have had a different experience or want to add on to mine, please do! It helps everyone, after all.