Recently I have been a contractor on a project that I have been given I little bit of grief (perhaps light heart, perhaps not) regarding the number of unit tests I have written in comparison to the production code I have submitted. Upon talking to some external mates in the development field there still seems to be some confusion as to why to test, how to test and when to test. I will happily admit that I am no TDD guru and am relatively new to the having only really being diligent about unit tests over the last year or so.

I did want to share some of my reasons, that may not be so text book, for using TDD. I will start with aspects of TDD, that on my most recent project, I have directly benefited from:

Define the Functionality of the Module
In the last project requirements were somewhat lose, so writing the unit test help the guy with the business know how and myself knuckle out what exactly we wanted these blocks of code to do. The people that will have to maintain my code as I move to the next project will probably find this module easier to maintain because of the reasonably well named and documented tests that are in place, meaning reduced ongoing cost of the code base.

Ability to Refactor with Confidence
As I was receiving information about the requirements in a piecemeal fashion, I was forced to write code for the functionality as I got it. This quickly became quite a large amount of code which later we found had aspects replicated across multiple classes. Refactoring these classes to strategies that inherited from a base strategy which inturn implemented an interface with the real business logic held in a handful of delegates meant we reduced the lines of code by 73%. As we refactored we made sure the entire block of unit tests still passed. The code is now a fraction of the size, very easy to read and maintain, fast and still fulfils the requirement set forth by the business. Refactoring all that code that took weeks to write was done in a day, in confidence because the unit tests were written up front.

Reduction of “Gold Plating”
In some case I get carried away and start writing things that I haven’t got a test for, because they may be needed in the future. This is by and large a bad habit of mine, I don’t get paid to gold plate, I get paid to provide a quality solution to a defined problem, even if that problem is not very well defined!
How has TDD helped? If it was not being covered by a unit test, it either needs to be or it gets removed. 9/10 it get removed as the tests are written first and they define the functionality.

Code Confidence
Although test don’t prove you code is good (see TDD Anti Patterns) it odes show that I have thought about what I am doing and give other developers or interested parties a direct view at what my code does. Most of my test methods are named so it is pretty obvious what they do, sure some get pretty long but I can find a unit for a module that I wrote months ago pretty bloody quick and figure out with in seconds the exact functionality. This is especially helpful if you have no BA support or business requirement documentation (yes it happens). Not only am I more confident in my code but I am more confident in other code if it is unit tested.

Encourages Correct Separation of Concerns
Especially when using mocks it becomes apparent when projects are starting to take on more functionality than they should.

Up-to-date Code
As I am writing tests for my code, as I go, I find that I am more likely to be within minutes of a previous compiling working solution. Formerly I used to go on tangents and write pages of code which may have been in a state far removed from a submittable state. If for some reason I was asked to shift on to other functionality I would have to shelve changes roll back and then work on something else. If I ever cmame back to that code I often had no idea where I was up to. Now I know exactly where I am up to… the method that breaks the unit tests! It is also more likely that I wouldn’t have to shelve as it is probably only a minute away from being in a compilable stae that I could check in to source control.

Easier to Make Changes
There have been some instances where the business requirements, or my understanding of them have been (a little bit) off. Having the test there means I can modify the test to assert correct assumption run the tests, see it fails and then make an isolated change in the code. As the test marry up nicely to the code the place where the change is required is very easily found and fix. ..Run test…. Pass test… Check in.

So how do i go about it? Well my”why” is covered above. For more reason check out http://www.testdriven.com or any other of the plethora of sites and books dedicated to TDD… as for the when and how…

When to test?
Before you have even written the functionality! Define what you want the method to achieve. You will probably find your self writing multiple tests per method and test fixtures are generally a lot larger than the class they test, bu the time you save in reduced debugging time and easier maintenance is well worth it.

How to test?
There are heaps of tools to use and can be a personal thing. Currently I am using TestDriven.Net with NCover and NUnit as well as ReSharper & Rhino mocks. As ReSharper is the only tool here I have paid for there is no reason not to get these widely used tools (I probably should throw some money at Testdriven.net).
Try to get a test project for each business project and a test fixtures should closely marry up with the projects classes. I don’t test minor thing like properties… there should be reason for the test!

Most frameworks now are very open to TDD, so there is very little reason not to use it. Right up to UI patterns, all but the view are very easy to test and mock. And as the view is completely stupid it should not have a lot scope for error.
So start testing; the initial growing pains are well worth it.

RhysC