Posted in:

In this book, Roy Osherove gives a comprehensive introduction to unit testing. He explains why you would want unit tests in the first place, how to go about writing and running them, as well as addressing some of the challenges involved in introducing unit testing to projects or development teams.

Those who have experience writing unit tests might not find a lot of new material in this book, but it is still worth skimming through as he often provides several ways of achieving a goal, one of which you may not have thought of.

Part 1 introduces unit tests and their benefits, and explains how they differ from integration tests. This elementary distinction is an important one as when many developers initially try to write their first unit tests, they actually write integration tests, ending up with tests that are fragile, unrepeatable and slow, and potentially putting them off from writing any more.

Part 2 explains how mocks and stubs can be used to enable automated testing. He shows that you can make classes testable using several techniques, not just passing in interfaces for all dependencies. He introduces a few of the most popular mocking frameworks.

Part 3 deals with the problem of managing and maintaining all your unit tests. He advocates continuous integration, keeping the tests simple, and presents a useful list of unit testing anti-patterns.

Part 4 tackles some of the tricky issues of introducing unit testing into a legacy codebase, or into a development team that is resistant to change. Osherove is a pragmatist rather than a purist. He recognizes that you may have to start very small, and prove that the time taken to write the tests is worth it.

Two appendices provide useful additional information on some of the OO design principles that make for testable code as well as summarising many of the open source and commercial unit testing tools and frameworks available. This is a very helpful resource, as it helps newcomers to navigate their way through the bewildering array of choices as well as highlighting some new tools that I hadn’t come across.

Overall I would say this is an excellent book to pass round developers in a team that is considering using unit testing or is new to the practice. Doubtless some will be disappointed that he doesn’t stridently demand that TDD is used exclusively, but his honest realism is refreshing and may even prove more effective in winning over new converts to test driven development.