Well its official The Gifford has turned me into a code coverage addict. After he helped me through writing my first unit test using NUnit the concept slowly started sinking in and I'm now addicted to code coverage. Writing NUnit tests is so easy that I don't understand why everyone won't do it, which is causing me to get a bit frustrated with people as it gives me the impression that they just don't care. I can't remember the number of times that I have gotten rather pissed because someone has changed my code and broken functionality and in some cases I've even broken my own code when I've had to go in and make changes after not looking at it for some time. Unit testing can minimize these hair pulling moments by giving you more confidence that what was supposed to be happening before you touched the code still happens after you touched it. If someone is in muddling around in your code and breaks something, you'll know immediately when they check in and the test doesn't pass on the build server. It all comes down to code quality and I have begun to notice recently that code quality everywhere sucks.
If you're not using unit testing of some sort then I think it just boils down to pure ignorance. Either you see the value of unit tests, but don't know how to write them and are too lazy to exert the effort to learn how, or you are just too ignorant to see the value of them. I fell into the first group. I've always seen how they could be helpful, but never took the time to learn how to do them. In the last couple weeks I've been really thinking about code quality with the product that I am building with a couple partners. We decided to build this product because we had gotten stuck working with another product that we thought had many problems and was a pain to work with. I realized that we were starting to walk down the same path, rushing to get a beta out, sacrificing design and architecture for deadlines. There are plenty of poor applications on the market and I don't want to be contributing to that. I want to produce a quality product or nothing at all because in the long run if we produce a poor quality product then we get stuck supporting that poor quality and our customers are stuck working with it. While assessing quality I kept coming back to our lack of unit testing and the fact that things kept breaking that worked fine the day before. This motivated me to overhaul the build server so that it runs NUnit tests automatically and then uses NCover to provide statistics on the code that is covered by unit tests and the code that is not covered. Then to take it one step further I built a screensaver that runs on the monitor of the build server that displays the overall percent of code coverage from the project in bright flashing red while it is under the coverage goal. (Currently FloFactory is at 9.5% code coverage with a coverage goal of 50%.) I look forward to the day that that text turns green to indicate that we have met our code coverage goal (and then I'll raise the goal).
I'm sure plenty of people would argue about the value of unit testing, pointing out various short coming with unit testing which I am sure are all valid in certain scenarios, but if you're following a tiered structure for your application, keep your logic out of the UI and keep your data access separate, then you should have an entire service layer that can be unit tested. Does having unit tests mean your code is perfect, of course not. It's not a silver bullet for quality but it is one tool to provide a bit more certainty about an application.
Where I am really struggling is motivating others to improve their code quality, understanding the importance of testing and getting them to write even one unit test. I realize that unit testing can't cover your entire application, but it's a start and if you start thinking about how you structure your application you'll starting seeing better ways to design things so that you can properly test them using such things as mock objects and inversion of control containers. The Gifford told me once that he goes by the statement "You don't have write unit tests, but don't break mine." Whereas I like this statement, I don't think it motives any one to write a single unit test, so I'm adding onto this by trying to make the statistics more visible. Hopefully if someone checks in code that lowers the overall coverage percent, that they can see very clearly on the build server screensaver, they may feel more motivated to raise that number.
As for myself, I'm going to keep digging into ways to increase quality so that the final product is stable and worth using. One last thing to point out is that if you plan to get started unit testing and are going to use NUnit then I would suggest picking up a copy of Resharper. It allows you to run your NUnit tests extremely easily from Visual Studio taking some of the headaches out of writing them.