I’m writing a fairly complex application right now, using VS 2005 and .Net 2.0

The reason that I mention VS 2005 is that it’s supplementing a lot of the tools that I used to use. NUnit, NAnt, NCover, etc. This is all well and good, but the cost of changing so much at a single time caused me to be slack in writing unit tests. Especially since I’m doing just the DAL right now, and I’m using Castle’s ActiveRecord and NHibernate so it practically writes itself. After writing several thousands lines of code I got really nervous as I contemplated the next step in the chain. I had a piece of code with very few tests, and I was going to use that to build the rest of my application?

So I’m writing stupid unit tests right now, because I’m too stubborn to let it pass as if it didn’t matter.

• Create the object; verify that all the properties are in the right value.
• Save the object graph to database, load it again, compare the objects.

Any now and then I get to do something that resembles real unit testing, where I actually get to test logic, and not mechanics. The issue here is that in the middle of all the tests that VS generously provided via code generation, I started to slowly carve my own tests. VS produce very extensive unit tests, most of them I discard, but it’s pretty good in making sure that I wouldn’t miss the important ones.

I found several cases where the unit testing framework in VS didn’t behave as it should, and the whole thing is actually driving me crazy sometimes. No easy way to just point at a test/class/folder and just run the tests there. And I can’t get TestDriven 1.1 to work on VS RC (that is, I can’t get it to handle the VS’ Unit Testing, it handles NUnit just fine).

What I did find was that even writing the tests after the fact, I started to improve the code, just so I could write decent tests. I’m not talking about refactoring; this is way too early for that and the code is pretty clean. It’s actually those little things like checking for null, and valid ranges, and the like, which I skipped during the first rush to get the DAL working (I tested several approaches to write the DAL, and you could probably say that the current code started as a spike.).

What is interesting is that I uncovered a few routine bugs, a misspelled configuration that would cause an immediate failure in runtime. I just fixed those without being impressed, since I would’ve caught them the first time I would’ve started the application anyway.

What really impressed me was during this routine test writing, I managed to stumble on a fairly subtle bug. I wasn’t saving some information to the database, so I was getting the default instance back from another routine. This may have very well escaped my notice, since even after finding it, I was convinced that it couldn’t happen, I thought about this scenario, and I gave a solution to it. When I arrived at the site of the bug, I found out that while I originally thought about it, I later modified the code and introduced the bug. If I’d a unit test then, I would’ve spotted it the minute I did it. I don’t like to think how this would have appeared if it managed to get to the working application stage, where you get a report about something totally unrelated and finally track your way to the root cause.

In short, Unit Testing is Good, but VS 2005 is still driving me nuts.