Test First and Test Later Methodologies

Test Driven Development argues that writing a test first and then making it pass as a development philosophy and practice will lead to less unnecessary code being written and consequently improve productivity. Additionally, since all code is covered by tests quality will be improved and maintenance made easier.

In the early days of extreme programming when the advantages JUnit brought to development were being explored the TDD folks were very dogmatic about this practice. The test first methodology found its way into many of the popular agile processes as well such as scrum.

Jacob Proffit wrote - three years ago now - on a study to determine if test first or test later development was more productive and obtained higher quality. Which is interesting as even now half the battle it getting all developers to unit test. However, the report seemed to find that:

The control group (non-TDD or "Test Last") had higher quality in every dimension--they had higher floor, ceiling, mean, and median quality. The control group produced higher quality with consistently fewer tests.

This is how I develop and only because I find it easier that way. I write the code and then ensure it is working through functional tests before slapping 100% unit test coverage over all the code that has been written.

For instance I am currently reworking the engine in this blog and moving it from python to java. I have functional tests that I write which hit the servlets directly and then i build the feature underneath it.

I make sure that the black box testing is correct and once it is I go over all the internal code that supports it and put unit tests over everything to make sure I haven't let through any bugs that the functional testing did not find.

At work we are currently building a new order capture system and this is the same process. I have orders flowing in through a remote interface which drove development. The first asynchronous part of it is complete and is now unit tested. The second part is still have some design and functional issues, but once that is hammered out then the unit tests will go over it.

I guess the thinking on my part is that once code is no longer volatile then it should be tightened up and made maintainable by unit tests.

But, like any ideal process, this is never always true in practice. Some methods become non volatile quickly and have no design issues. So they can be unit tested immediately. For instance we have some restrictions on what data must be presented with an order so that we can bill and fulfill the order.

These don't change and if they are wrong can destroy all functional testing, so they were unit tested as they were written to make sure there were no bugs from the restrictions. So the whole thing is fluid and comes down to the individual developer and how they are more comfortable writing code for a particular situation - as long as they unit test.
cam 2011-12-04 11:40:22.0