Mark Needham

There have been several times where we have been writing code in a test driven way and it has been suggested that we would be able to go much quicker if we stopped writing the tests and just wrote the code.

I feel this is a very short term way of looking at the problem and it does eventually come back to haunt you.

One of the problems seems to be that in many organisations only the first release of a piece of software is considered, and in this case then yes maybe it would be quicker to develop code in a non TDD fashion.

The issue you have is that the majority of the overall cost of software does not come in that first release – if we assume a total life time for a piece of software to be 3 years and the first release takes 6 months (being generous here!) then if we go at full speed in those first 6 months and don't write a good suite of tests, we leave ourselves with 2 1/2 years of maintenance hell.

This is where the real cost in software lies. The end of development on a piece of software is very rarely after that first release – bugs need to be fixed, new requirements come in and changes have to be made. Without the tests in the former we are left fixing something and hoping it works – I have broken stuff in production by making changes in non test driven code unaware that it would break elsewhere.

Even if we look at the development cycle of a single release, at some stage we are going to have to test the code we've written to ensure it actually works.

The TDD approach to doing this encourages early testing whereas the traditional approach is to do a lot of the testing at the end. The problem with the latter approach is that any bugs are being discovered quite a long time after the code was written which means it will take much longer to try and identify where they came from. Alex has a nice post showing the risks we assume when deciding to cut back on testing effort.

In terms of whether or not actual development time takes longer with TDD, Microsoft recently released a paper which suggested that code written using a TDD approach takes longer to write originally but puts less bugs in production.

Since the goal of software development is to get code into production I think perhaps we need to consider the whole period of time from when a feature was worked on until it is in production as being development time.

Clearly there are times when time is the biggest driver for when something needs to be released but the majority of the time having software with less bugs is probably preferable and TDD is helpful for achieving this.

A couple of my colleagues have been posting about how to name your unit tests based on this original post by Jay Fields.

I think that test names are useful, especially when written in a BDD style expressing what a test is supposed to be doing.

For example, in a C# NUnit test we might see the following as a test name:

[Test]
public void ShouldDoSomething()
{
	// Code testing that we're doing something
}

I write all my tests like this and I'm often asked what the point of the 'Should' is, why not just name it 'DoSomething'.

For me although it's a subtle change it influences the way that people look at the test. They can look at the test in a much more critical way.

In the above example someone can look at the test name 'ShouldDoSomething' and then think 'Actually no, it should be doing something else.' The test name and the test contents can then be changed to fit this new understanding of the test.

I'm with Chris Johnston who says the following when it comes to naming tests:

One habit that I picked up on my last project was naming a test after I had written it. While creating the unit test, I would simply name it foo(). Then, once I saw what the code was actually doing, I would go back and rename the test to something appropriate.

Ideally I want to name the test properly before I write it but sometimes it becomes clear to me exactly what the name should be as I'm writing the test.

If I'm in this situation I usually just name the test 'ShouldDoSomething' and then by the time I've written it I know what it should actually be doing and I can go back and rename it.

In terms of the general argument over whether we should even have test names, I have only really coded tests in Java and C# so I'm not in a position to comment on whether using a language like Ruby means that they aren't necessary.

For me the test name provides the intention of what you are trying to do, and I like to skim the list of tests in a class – by using Ctrl – F12 and then typing in 'Should' to filter the method list in Resharper – so that I can see at a high level what is supposed to be happening in that test fixture.

In the world of IntelliJ there is also a nice plugin called TestDox which allows you to get a list of your tests nicely indented with spaces.