I’m a big fan of using unit tests during the development process to facilitate writing code. In fact, I like writing my unit tests at the same time that I write the code. I say that slightly tongue-in-cheek, because by phrasing it as “at the same time” instead of “before”, I’m bucking the typical TDD (Test Driven Development) mantra of “write your unit tests before you write your code”. For the kind of software that I write on a daily basis (proof-of-concept scientific simulation codes), there is a very high probability that
- I will be the only user
- I need to finish the software as fast as possible
- The code will most likely be thrown away when it’s done (or at least used only as reference for the next project)
- The code will not be revised in the future
It just doesn’t make sense to spend tons of time on the unit tests if they will never be used later.
That being said, the ability to write and run small snippets of code that exercise various portions of the program as you compose it has a huge productivity gain. It really allows a tight development cycle — new functionality can be added and directly tested without needing to start the application and click through a number of menus to run the code you just wrote. Just build, fire up your unit testing framework, and see if it worked or not. You can even set breakpoints in the unit testing code and step through everything from within Visual Studio. If all the tests pass, I can be reasonably certain that my code is in good shape. I like to think of this pseudo-TDD development (where tests are developed alongside code) approach as “TDD-Lite”.
There’s a small problem with this approach — seeing all of my unit tests pass can give me a false sense of security. Sure, all of the tests might have a green light, but I might just be testing the wrong conditions, be testing the wrong code, or simply not have enough tests. Thankfully, code coverage tools exist solely for this purpose — to check your unit tests and let you know exactly how much of your code was actually tested.
How can you easily accomplish this? My personal favorite combination of free/open-source tools includes NUnit for the unit testing, NCover and NCoverExplorer for the code coverage, and TestDriven.net to tie everything conveniently into Visual Studio 2008.
If you want to try it out, the only thing you need to download and install is TestDriven.net. It actually comes packaged with NUnit, NCover, NCoverExplorer, and a number of other familiar unit-testing tools. After installation, it adds a menu to Visual Studio so that whenever you right-click on a project, you can fire up your unit testing framework of choice:
For example, if I run NUnit 2.4 (right-click, Test With… NUnit 2.4) on my project, I get a window that looks like this:
Notice how each test shows whether it passed (green) or failed (red). Right now all of my tests pass, which makes me very happy
If I run the code coverage option (right-click, Test With… Coverage), it spawns NCover. NCover is a command-line program that runs NUnit in the background and exports an XML file describing the results and the lines of code that were tested. Then NCoverExplorer (the WinForms GUI) is launched to show you the overall coverage results visually. Check it out:
This is an amazing combination! Not only can I run unit tests to exercise certain portions of my code, but I can see exactly which branches of which functions aren’t being tested (exception handling is most common). Also a coverage percentage is calculated for each method, property, namespace, and assembly. Absolutely fantastic!
Unit testing and code coverage combine in an extremely powerful way, thanks to the amazing work by Jamie Cansdale with TestDriven.net (not to mention all of the open-source developers that have contributed to NUnit, NCover, and NCoverExplorer). Even though I can’t take full advantage of all of the benefits of doing full TDD, I certainly appreciate the ability to run fine-grained tests against specific portion of my code in a very straightforward manner.