The Art of Unit Testing Book Review
I have a few confessions to make. First, I still read books, although for technical books I've switched to electronic formats instead of dead trees thanks to my long-running Netbook. But I just prefer the format of concise and complete information logically grouped together. Blogs and sites like StackOverflow are nice for specific topics, but even article series in blogs often cannot compete with the layout of books.
My second confession is that I do not practice Unit testing. Sure, I've spent some time reading about Unit Testing and played around with both NUnit and xUnit.net, but I never made tests that were more complicated than calling a function and asserting on the result. Mainly because I never understood more complicated concepts, I was never sure about the difference between unit and integration testing, and I thought that Mock Framework is black arcane magic.
Mainly because that's what most blog articles in the internet tell you. There are plenty of articles among the lines of "Assert(4,Add(2,2))" but that's about it. There are plenty of other articles about Unit testing, but I did not find any "Tutorial" that goes all the way from a simple assert to a full-blown solution involving stubs, a mock object and a database.
Until two weeks ago. I was browsing Manning for another book (C# in Depth, Second Edition by Jon Skeet) and saw Roy Osherove's The Art Of Unit Testing. I was looking through the reviews at Amazon and decided to buy it - and I am absolutely thrilled by it!
First, it's a very practical book. Roy doesn't have many long-winded explanations, but instead he briefly introduces a concept, then presents some (C#) code, and then explains a bit more. This is great, because it allows the reader to take baby-steps. He starts writing Test Code without a Unit Test Framework to introduce the concept, but then quickly switches to NUnit throughout the rest of the book. That's a nice little touch because for people who have absolutely no idea what problem Unit Test frameworks solve, this should explain it.
It then goes on to some more complicated (but more real-world) scenarios, i.e. involving testing a function that normally calls the file system. Again, Roy first illustrates how you could do it entirely manually (briefly covering dependency injection) before he moves on using a Framework. Only after laying all the groundwork he starts involving a Mock Framework - Rhino.Mocks - and starts with relatively simple scenarios as well.
This may sound like a "How to use NUnit and Rhino.Mocks" book, but it isn't. As said, Roy explains all the concepts and starts building completely manual solutions at first, which means that all concepts should be known and you should easily be able to adapt it to whatever Unit Test and Mock Frameworks you use.
And that's the beauty of this book: It's about concepts, explained through practical examples. If you know what a Mock is and how it's different from a Stub, if you know the difference between Unit and Integration testing, if you know how to approach any given problem, it does not matter what framework you're using.
The little icing on the cake is the chapter about "Working with legacy code" which explains how you can add unit testing into existing applications, which can often be overwhelming if the legacy application is old, big, badly documented and mainly held together with duct tape and prayers, which means that no one wants to touch it.
Now, no good review is complete without listing some negative points. (Side note: Any review that is absolutely and 100% positive is not a review, but a marketing publication and therefore useless): Mainly, I would have wished a bit more about unit testing user interfaces. Neither ASP.net nor WinForms nor WPF is covered, although there is a whole Appendix at least listing additional tools and frameworks. I think there would be some room in a second edition to make a mostly complete Step-By-Step-Tutorial even more complete.
Conclusion: It's great that Roy Osherove is the author of this book, because he is not just an expert on one specific framework, but he rather knows about the whole concepts and foundations of unit testing. That results in a well-balanced and complete book. He uses NUnit and Rhino.Mocks only as a "device" to explain the concepts instead of making them the "stars" of this book.
I can wholeheartedly recommend it.
I bought the book after hearing him on Hanselman's podcast but have put off reading it. This review motivates me to devote some time to reading this book...finally.
I think the reason that you don't see and won't see a lot of coverage of unit testing a view layer is that they are often very expensive to test and really difficult to isolate as units. Views often require integration and/or systems testing. So I'm not sure that should be covered in a book on unit testing. Spinning up the .net framework to test a view is no longer testing a unit as the dependencies on the underlying framework haven't been isolated. The same can be said for WPF, WinForms, WCF or any other framework that cannot be isolated and is required around the edges of your application.
Striving to make views very simple through MV* patterns often removes a lot of the code from the view and leaves less room for failure. Theoretically, a good view only has wire up mechanisms to extract/present data and to forward commands. Beyond that you can look to frameworks that do integration testing to provide you with the tools to test views. I would also stress to be careful of the extent of testing you do here as it can become very expensive and result in brittle tests, especially if they are long running and often only are tested in a CI environment, say on a daily basis (highly likely chance people will break tests if they aren't constantly running them). A lot of people encourage simple smoke screen tests as the best ROI for testing the view layer. Thoughts?
I should probably write my own review of this book, but to quickly point out Chapter 7 as being the most profound chapter in my mind as it presents many Best Practices that can make the difference between good and bad tests. This fundamentally changed how I look at unit testing. Thanks Roy!