Book Review: The Art of Unit Testing by Roy Osherove

Resources

• Manning – Where one can buy the MEAP early release of the book
• Amazon – Sometimes cheaper than Manning for print books
• Art of Unit Testing Wiki Site -The wiki site for the book
• The book will be in print I think April 2009 as Roy mentioned in his blog if you wish to wait for a hard copy

Additional Information

• Paperback: 225 pages
• Publisher: Manning Publications (May 1 2009)
• Language: English
• ISBN-10: 1933988274
• ISBN-13: 978-1933988276

Audience and Content

The intended audience for this book are people who are beginning/intermediate learning unit testing or in the process of implementing unit testing at their shops. The contents is for developers to start writing better unit test. I wouldn’t say it is a book target at expert unit testers out there, people who may already be using SpecUnit or BDD, since the book doesn’t cover BDD or Spec. But nevertheless it still has valuable information for everyone.

What is it all about?

Part I Getting started

The first two chapters 1 and 2, goes through the basic of what unit testing is, (definitions, intro to nunit) and writing your first unit test using nunit. The author touches a bit on TDD but not going into details of it, since I think TDD is another mind set and the author just didn’t want to overwhelm the reader (if they were beginners). In the book he also uses the example of a Logger which he builds upon to explain the techniques of unit testing.

Part II Core techniques

The second part of the book chapters 3, 4 and 5, details the core techniques of how to use stub, what mocks are and using mocking framework Rhino Mocks to do unit testing. These three chapters I believe are quite important for a beginner to go through, since in chapter 3, the author goes through the techniques of Extract and Override, using Factories and Dependency Injection through constructor/properties. The author also talks about when should one use these techniques, the pros and cons of them.

In Chapter 5 he introduces Rhino Mocks, (also mentions other frameworks, Typemock, NMock2) although he uses the “using record/playback” way of Rhino Mocks (i.e. not using AAA style or the fluent way) of coding the examples, not that there is anything wrong with it, personally I prefer the AAA style and using lamda expressions. If you are looking at technical information or the meat of things, these three chapters are definitely the core of it.

Part III The test code

In part three of the book chapter 6 and 7, the author explains the important of using build automation, and continuous integration. How to separate out test so that they are in different folders/projects for integration and unit (i.e. slow and fast test). Also some techniques of refactoring your code to use base class/template method/generics to reuse code, although warning that base class etc might lead to less readability of the code.

In chapter 7, the author goes into the explaining trustworthy test by using coding standards (naming of test), some basic principle of DRY (don’t repeat yourself), code coverage, testing only one thing, using only one assert statement and finally using attributes to test different input cases of the test, rather than writing test for each case. I think this might be the chapter that some might considered it controversial, since they might see this chapter as in telling readers (laying down the law) of how to create trustworthy unit test. I would only say to that, give it a read and nobody is pointing a gun and saying this is the way to do it, I don’t seem to remember reading a book and following it the exact way of coding or using the exact libraries the book uses. Yes, things that the author list out might be valuable but at the end of the day whatever fits your boat or shop is what matters.

Part IV Design and process

The last two chapters 8 and 9 talks about integrating unit testing and working with legacy code. Chapter 8, was the chapter that had the most importance for me personally, on bring change and unit testing into an organization. Although there was an error on Table 8.1 which had the amount of bug found in production for teams doing test and not doing test, they were in reverse, I guess a typo from the author. The last chapter 9 talks about where should one start introducing test in your code, the hard part or the easy part, where does it pay off and some tools to use for unit testing. The author also uses the 4 quadrants to map out easy/hard test with dependencies, so that one can pick what would be easy and hard to test.

And lastly in Appendix I and II, the author talks about using design for testability and some tools/framework. In Appendix I, the author lays out a table of design guidelines and benefit of using them. What I found lacking was the cons of using the design, I think a column that also included some cons of using these techniques might be a better and be well rounded for readers to choose which design to use.

Conclusion

Last but not least, would I recommend this book to anyone? The answer is definitely “YES”!!! I would give this book a 4.2 out of 5 stars, I only wished the MEAP version didn’t have so many typos but hopefully when the final release comes out it would be all corrected.