The art of Unit Testing with Examples in .NET
The Art of Unit Testing: with Examples in .NET by Roy Osherove
I recently bought a copy of The Art of Unit Testing: with Examples in .NET by Roy Osherove, taking advantage of a discount being offered by Manning.
Already owning xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series) by Gerard Meszaros and Working Effectively with Legacy Code (Robert C. Martin Series) by Michael Feathers, I was interested to see what new insights Osherove would bring, especially as he would be focussing purely on the .NET platform (code samples are in C#).
The book is divided into 4 sections.
Part 1 (which I skimmed through) was an introduction to unit testing. Osherove uses NUnit for his examples which is reasonable considering it is probably the most popular unit testing framework for .NET at the moment.
His preferred naming convention for test methods is interesting – “[MethodUnderTest]_[Scenario]_[ExpectedBehaviour]”. It contrasts with the “natural sentence” style I currently favour (which I’d trace back to Jean-Paul Boodhoo’s unit testing episodes on dnrTV).
He also recommends naming test classes with a “Tests” suffix. I’ve always used the singular “Test”, but I take his point that each test class does contain multiple tests so plural may be more accurate.
Part 2 introduces stubs, mock objects and isolation frameworks (aka mock object frameworks). Following a poll held on Osherove’s blog, Rhino Mocks was chosen to demonstrate how a framework can simplify creating mock objects. I could be wrong, but you almost get a sense that this was done somewhat grudgingly considering Osherove himself works for TypeMock (who sell a commercial mocking framework). Curiously whilst including a link to the Rhino Mocks download site, he doesn’t even mention Ayende’s name at all.
Osherove makes the following recommendations about stubs and mocks:
- Use nonstrict mocks when you can
- Use stubs instead of mocks when you can
- Avoid using stubs as mocks
I found this interesting, as we’ve been writing a lot of unit tests lately, and one of the things we’re coming to realise is that brittle tests can be annoying. Tests that still test your code, but are more flexible about exactly how the code under test works (rather than setting strict expectations for each and every method call) are going to be more useful and less effort to maintain.
Part 3 looks at various strategies for organising tests and a number of patterns and anti-patterns to follow when creating tests.
Part 4 covers how to make unit testing the norm in an organisation, and how to work with legacy code.
Having some experience writing unit tests, I did find this book a bit light on. Osherove references Meszaros and Feather’s books regularly. I would also consider both of these works cover the topic in a more detailed and thorough manner. However they are probably not necessarily as good a starting point for someone new to unit testing, especially someone who’s main experience lies in developing for the .NET platform.
I finished the book surprisingly quickly – pleased that I’d learned a few new things, but left feeling that it would have been nice to learn a few more.