The Art of Unit Testing: with examples in C# 2nd Edition by Roy Osherove

When I was a young programmer, I remember a job interview where I expressed my belief that coding was a form of art to a potential employer. The job was for an entry level position working with the RPG language on IBM systems. I knew very little about RPG at the time, but I was confident I could learn. I did not get the job and looking back, it’s clear to me that immaturity and lack of experience where the main reasons. Even still, the exchange about art stands out in my mind and I often wonder how that affected the outcome.

Some years later, I discussed this interview with a respected associate. He explained to me that managers and especially those above them usually see software development as a complex machine with many moving parts. In order for this machine to function efficiently, each cog and gear must be predicable, measurable and reliable. There is sometimes very little appreciation for art in this point of view and in many ways I agree. Much of software development is about the pursuit of correctness and certainty, the elimination of risk and the maximization of value. Despite this, I still believe that art must play an essential role in any venture for it to be truly worthwhile when all the amounts and values are finally summed. The Art of Unit Testing delivers the best of both worlds in a way that is direct, practical and immediately applicable.

I was first introduced to Roy Osherove’s work indirectly through the MVVM design pattern. I was researching it for a WPF project when I realized that it would be a great chance to learn about unit testing. I google’d the topic and discovered artofunittesting.com. After watching all of the videos, which were excellent, I gave the usual sales pitch to management and then opened up the beautiful can of worms that is legacy code. In the end, the decision to include unit tests in the project impacted the schedule significantly for the worse. I had to rewrite perhaps a third of the codebase and abandoned the idea of unit tests for the rest. The code was still buggy and when I joined another team a few months later, the existing unit tests were forgotten. Based on this, it would be easy to conclude that unit testing failed to produce value.

A year or so later, I decided to try TDD on a small project and picked up The Art of Unit Testing to give myself a jump-start. Although not specifically about TDD, this book is regarded as one of the best on the subject of unit testing in general, and having read it twice now, I have no reason to disagree. Unfortunately, I was not prepared for the system shock that exposure to the TDD worldview can produce. On one hand, the TDD code that I wrote was perhaps some of the best code I’ve ever written. On the other hand, the project went so far behind schedule as I adjusted that it was put on hold indefinitely. Based  on this, it would be easy to conclude that TDD specifically and unit testing in general failed to produce value.

Just last year, I was assigned a high risk, high profile project with a critical dependency on another sizable and legacy component. The main project required several complex changes to the legacy component and these assignments were given to developers who did not practice unit testing. The result was an extremely buggy and unreliable system and we wasted at least a month tracking down issues and troubleshooting them. Eventually, I realized that it would be better to rewrite it from the ground up and so I did–with a testable design and about 90% code coverage. I was able to do this in a reasonable time frame and the component has been rock solid ever since. No issues at all were found in QA and none have been found in production. Based on this it would be easy to conclude that unit testing successfully produced value and I would agree. It allowed us to complete the high risk, high profile project with a high degree of certainty about the correctness of the final behavior without negatively impacting the schedule. It was in fact the lack of unit tests and unknown code quality that posed the greatest risk to the project schedule.

It is important to realize that the last success would not have been possible without the first two failures. What you will gain from The Art of Unit Testing and pursuit of the discipline in general is not a magical power-up for your next project, but the skills you need to become a stronger developer in the long term. You’ll learn the basics of writing unit tests, you’ll survey the commonly used tools and you’ll be exposed to the concepts required to write readable, high quality, maintainable tests from the perspective of a veteran in the field. The transition to becoming proficient in this discipline won’t take place overnight, but The Art of Unit Testing will help make this worthwhile journey faster and less painful.