Random Code

I am learning TDD. It’s hard and I often fall back into old habits of writing code before writing tests – particularly when I can “see” the solution (I tend to code from within existing classes out, meaning I still write the code the way I’d like to use it but not from the tests). This leads to patches in the code that are quite often not tested, and not always required. I found the trick to identifying these patches of code (and quite often refactoring them away or simply deleting them), is to use a code coverage tool while running the tests so I can see what isn’t tested.

I use VS2005 Pro and NUnit for my testing needs. I don’t have any budget to go and buy tools so the commercial code coverage tools were out, however I found that you can still get the earlier versions of NCover and NCoverExplorer for free, and right now they do just what I need. Setting them up is easy:

1. Make sure you have NUnit installed, setup and running from the console – I am using 2.4.6 for .NET 2.0
2. Get the last free version of NCover and install it – I am using 1.5.8 beta
3. Add the locations of nunit-console.exe and ncover.console.exe to your PATH environment variable
4. Grab a copy of NCover Explorer 1.4 from here
5. Run NCover Explorer, hit Ctrl+N to Run NCover, configure NCover via the NCover tab and the application to profile via the Application to Profile tab (the Application Arguments will be the name of the assembly containing the NUnit tests) and if you want to limit what is profiled, use the options tab to customise your profiling.

Once you have the profile results up, you can navigate the coverage and see where your tests missed things and look at what you need to do to test what is missed. Critically analyse code that has not been tested, particularly where a majority of the code around it has been covered. I found myself refining the untested code based on one of the following questions quite often:

• Do I really need that guard condition?
• Is the scenario I have allowed for likely to happen?
• Should I be handling that case differently from the rest?

Although it is nice to get code coverage up to 95%, I am realistic about what I am testing. It is a (relatively) small system I have previously talked about, and that means a lot of simple property get/set type code and some “untestable” code that integrates it into the underlying web application (primarily in the global.asax and container / component registration). My primary goal for using code coverage was to identify complex and / or significant parts of the system I had written while in a code first groove and get them under test as soon as possible. Now I have NCover up and running, I am trying to make it a habit to run it every couple of hours to catch those places where I have fallen back into old (bad?) habits.