.NET Musings

Just saw an article on InfoWorld that says "Unit testing adoption appears to stumble". The biggest support the author offers for the title is a failed commercial product (starting at $37,500 US) collapsing. He goes on to state that his readers believe "that unit testing seems to offer little value". Evidently his readers don't know how to unit test.

I have been testing code as long as I have been writing code. Since my very first "project" (I modified the code for SubHunt on the Apple II because I didn't like to lose), I tested the code. Now, we would call that integration testing, but it is still testing.

As I moved to "real" projects (not to say games aren't real, I just haven't found anybody to pay me for playing or writing games), I tested every piece of code through a custom developed test harness. This might have been a console app or a winform (current terminology), but nonetheless I exercised my code. Sometimes is was even as crude as stepping through the code in the debugger, dumping variables out to a watch window.

Was it painful? Absolutely. You know what was more painful? Handing code over to the client and them not paying you because the project failed.

When .Net came out, and I started getting deep with Microsoft and the managed code world, I jumped on NUnit as a testing harness as soon as it was available. I couldn't believe someone had developed a tool that would make testing my sofware so incredibly efficient. I began to evangelise to anyone who would listen the benefits of using a testing framework.

I was brought on to a gig at a client in 2001 as one of several software architects, and one of my roles was to recommend and then teach development practices. While holding a lunch and learn for NUnit, I saw several developers getting ready to lynch me. I finally asked what the issue was, and they told me this will take them twice as long to do compared to how they are currently developing. I spent the next 30 minutes trying to convince them that this would save them time in the development cycle, until I discovered that they weren't testing their code! According to them, that was the tester's job. As long as their code compiled, they were done until they got assigned a bug.

This sent me realing for a bit, until I realized the problem wasn't what framework to use, it was understanding the need to test your own code.

I then switched gears, and instead of promoting this framework or that framework, I started coaching and mentoring on writing good unit tests (see my blog post here on what makes a good unit test).

As I became more of an agile developer, I moved into more of a Test Driven Development mode for myself and senior members of my various development teams. I also spend a fair amount of time speaking on the subject. But not everyone is ready for TDD. There is indeed a learning process, and the foundation has to be well written unit tests.

I love Jeff McWherter's term TED - Test Eventually Development. The goal of software developers is (or should be) solving the problem at hand with as little code as possible, and getting it right the first time. If I can get a developer to test after the code is written, it is indeed a stepping stone towards the "getting it right" part of the goal.

Once they understand the benefits, then we move into the test first, which helps to satisfy the "as little code" as possible part. After all, if I can write less code and significantly less bugs, that leaves me more time to shoot bad guys in Ghost Recon Advanced Warfighter 2.

I have never had a problem with management turning down migration to a test first strategy. Maybe I'm that good at sales, but I don't think so. I just quote all of the studies that show costs of defect resolution throughout various stages of the development/test/release/production support cycle. That is usually when they ask me "What is the current code coverage on my project".

Unit testing is not a silver bullet, nor is code generation, ORM tools, or anything else. The only silver bullet is critical thought. (Thanks to Leon Gersing for constantly shouting that out where he goes. Thought about the tests, thought about the tools, thought about the code you are about to write or (more importantly) not write.

A well written suite of tests developed through critical thought can save a project from support disaster, can make the development team heroes, and maybe even get a game room installed in your office.

Happy Coding!