The Art of Unit Testing by Roy Osherove

One Minute Bottom Line

Review

As a developer who started working in Visual Basic 15 years ago and only began to explore unit testing and Test-Driven Development (TDD) in the last four to five years, I was blown away by The Art of Unit Testing. I wish this book had been written many years earlier. Roy Osherove is an architect at Typemock, and was instrumental in helping to launch the ALT.NET movement. The primary goal of the movement is to foster good coding practices within the .NET community. In many people's eyes, unit testing is the most important of these best practices.

The code samples in the book are written in C# and the tools referenced target .NET, but the concepts apply to any language or platform. Perhaps the only drawback of the book is that it does not provide platform-agnostic examples, but I think it would take away from the usefulness of the book to try and do so.

The book begins by explaining what unit tests are, why they are important, and what a simple unit test looks like. The author takes the time to explain what makes a good unit test and how a unit test differs from other types of tests, such as integration tests. Some of the first examples illustrate how unit tests can be hand-written without a unit test framework (although this approach is not recommended given the availability of these frameworks).

Throughout the rest of the book NUnit is used as the test framework for Roy's examples. He explores the unit testing techniques of stubs, mock objects and isolation frameworksin the second part of the book. Some developers do not differentiate between mocks and stubs, but the author explains the difference and how each falls into a category of objects he calls 'fakes'. Rhino Mocks is used in the isolation framework samples, but the book references other frameworks available for .NET and the advantages of each.

The next two sections cover some best ways to approach writing and organizing unit tests. The author dives deeper into what makes a unit test a good test, asserting that a good test should not only tests what the developer intends but it should also be trustworthy, maintainable and readable. Finally, some processes are discussed, including how you as a developer can introduce unit testing into your own organization. Practically every major hurdle you might encounter has been addressed in the book: integrating with legacy code, ways to get others in the company on board, and where to start (entry points).

If you do not own a copy of The Art of Unit Testing, it should be the next book you buy.