A few weeks back I noticed that Agitar software was winding down its operations. I guess that's business speak for going out of business, but for sale if anyone wants to come and bail us out. Jerry Rudisin, the former CEO, stated the primary reason for Agitar's demise was that the market was not big enough to support the kind of value business they wanted to build. I also remember reading a quote a while back by Alberto Savoia, one of the founders of Agitar where he made a blanket statement that people just aren't doing unit testing. I hope he is wrong.
Unit testing is the closest thing to a silver bullet we have in software quality. So why doesn't everyone writing software do it? Because to do it right, it takes a tremendous amount of effort, which equates to cost. And when faced with limited resources and a mountain of desired features, most decision makers will choose features over quality every time because after all, features sell software. I am as guilty of this as anyone. Ideally, we would have >95% code coverage in our applications, but we don't. So how does unit testing improve quality so much?
- It makes developers think about more than just making their code work. It makes them think about how to break it. And when they do this, they write better code.
- Code is executed in atomic units while it's developed, increasing the chance that when everything is integrated together, it might actually work.
But the BIGGEST and BEST bang for your buck you get with unit tests… you get to know when changes break your software. REGRESSION! That's the big bang baby. That's what makes unit testing worth the investment.
Software is iterative. Release early and often. Iterate. Let your users tell you want they want, and then give it to them. I am sure you've heard that before. And it's great advice. But if you are trying to make software with 0 quality defects, or in user terms, no bugs, this iterative tactic works against you big time. ANY change to released code is bad and there better be a good reason for the change. This is a really hard point to make to the less experienced software gurus, who think if code looks bad, doesn't conform to current coding standards or could obviously be constructed better, they should just change it. NO! Any change, as benign as it looks, can break stuff. So then how do we make changes without killing the app? UNIT TESTS.
A good battery of unit tests is your ace in the hole. If you have them, maintain them, and protect them, unit tests will allow you to iterate and maintain a very high level of quality in your product over time.
So are people really not doing unit testing? I respectfully disagree with Mr. Savoia. I think they are. We are. I stated that to do them right requires a tremendous amount of effort. Agitar's problem is not market size. You simply cannot build (or buy) a tool that will do this for you. We are not talking about spell or grammar checking here. That's what FxCop does, to a certain degree. Unit testing done right requires simply using the tools that are readily available such as NUnit or MSTest and taking the time to write the tests that execute your code. When you do this, you will write better code. You focus on the edge cases. You think more about what the target code is doing. When you do this, you give your application that ace in the hole that allows you to iterate without significant quality issues. And this is why unit testing is profoundly worth the effort.