Book Review: The Art of Unit Testing by Roy Osherove

by Aaron 13. September 2011 22:19

Let me start off by saying, I didn't seek this book out.  It was recommended by a friend after I read "Working Effectively with Legacy Code" by Michael Feathers (see my review here).  With that, here's the bad, the good, and the summary (in that order!).

The Bad

First, the bad.  The book (official site) itself wasn't bad.  Unfortunately, I didn't learn much from the book.  I had followed up Michael Feathers book with this one, and maybe that was the issue.  Michael Feathers book was densely packed with tons of information.  "The Art of Unit Testing" felt pretty light in comparison.

There was nothing really ground breaking about the book.  A good amount of the information presented is information that can be easily found around the web, in samples from the unit testing tools available, and in other books that maybe aren't even about unit testing (link). It made more than a couple of references back to Michael Feathers book encouraging the reader to maybe go look at that book.

The Good

It was written well and easily understood. I feel like it's organized well.  It also goes into detail about techniques you can use to try to integrate unit testing into your organization.  The author himself has been through the scenario multiple times and is able to relate his experiences.

The first thing that was new to me was how to hide some of the constructors from the public interface, but make them visible for testing.  Declare them as internal and add the InternalsVisibleTo attribute in the AssemblyInfo file.  That helped settle a disagreement I was having with one of my former coworkers.  He felt reflection should be used to set fields and properties instead of using dependency injection techniques like overloaded constructors.  Declaring the constructors as internal gave him more of a warm, fuzzy feeling than having them public, and it let me do what I felt was best.  So thanks for settling that Roy!

The author was working for Typemock while writing the book.  He even gave that disclosure multiple times throughout the book in an attempt to dissuade the user from feeling like he was secretly trying to sell the reader on Typemock products like Isolator.  He did give lots of examples using Typemock Isolator, but they were to demonstrate what's possible with various tools.  Typemock Isolator definitely has a lot of power and features, as it should since it's a commercial product.

While a lot of examples were around Typemock Isolator, many (and probably more) examples were given using Moq and Rhino Mocks.

The other place that I found useful information was in the appendices.  The appendices went through and described various tools that can fill various needs in testing (unit, integration, and even acceptance).  The listings and descriptions were really good.  It pointed out some tools that I didn't know about and plan on investigating.  For now though, I'm pretty happy with, MS Test, and Moq.


Overall the content in the book really felt too too basic for me.  Maybe that's my fault for following up the Michael Feathers book with this one.  Maybe I expected the same level of detail and amount of content that was in my previous read.  Maybe I'm just wicked smart!  Who knows?

I wouldn't recommend this book to anybody except people that are looking to get started with unit testing and haven't read Michael Feathers book yet.  I feel like this might be a better book to start with and followed up with Michael Feathers book "Working Effectively with Legacy Code".  Reading in that order may lead to better enlightenment.

While it was pretty basic, I did get some useful information out of it.  Now though, it'll probably just collect cyber dust sitting on my cyber bookshelf (I got the eBook version if you're wondering what the hell I'm talking about).

Tags: , , , ,

Book Review: Working Effectively with Legacy Code by Michael Feathers

by Aaron 22. August 2011 04:09

The book isn't new (published in 2005), and I'm certainly not the first to review the book (link).  I'm also not the first to tell you, it's a good book (link).

I could just leave it at that: it's a good book.  But I feel like I should tell you why I think that: because it's awesome!  Also, it's written by a really smart guy.

If that's not reason enough, here's some more detail.

When I started reading the book, I was a little apprehensive.  I was told the book is pretty dry and dense.  I was more than a little surprised to find that the book was a real page turner!  I rarely go through a technical book wanting to read the next page or chapter because of the very reason thing I was warned about with this book: dry and dense.  I couldn't put this book down.  I raved to Chris Slee about it repeatedly.  I know he was tired of hearing about it, but he was a good sport about it,  I think he even bought the eBook eventually.

Early in the book, there's mention that the book doesn't need to be read cover to cover, and it's okay (recommended even) to skip around.  There are references to later pages and chapters related to the current topic.  Those are pointing you to the part of the book that defines and describes the pattern/technique being described.  That's the one thing I did wrong: I didn't go to those while I was reading.  Why?  Because I'm OCD about not skipping around in a book.  I also thought that it was making reference to other sections, and I was afraid of getting lost!  My fear was unfounded.  One: I'm a man.  Men don't get lost.  Am I right, guys? Huh?  Two: it was just to read through the technique.  I have a finger and book marks,  I could have saved my place and gone right back.

Even though I did it wrong, the book still changed how I do my work.  That applies to both greenfield and brownfield development.

The book uses C++, Java, and .NET for examples, but the techniques can be applies to other technologies.  That is, if you understand it.  I glossed over the C++ examples and techniques.  Not because I don't care, but because...well...I guess I don't care.  I don't do C++ development, and my exposure is usually pretty limited to it.

I actually finished reading this book months ago, but it still stands out in my mind, and my work reflects the things I learned from it (you're welcome everybody working with my most recent work).  It made that much of an impression on me.

To make a long rambling shorter, the book was very good.  It was a little dry in a few places, but the information was presented very well throughout the entire book.  I now have a much different and better view of what a unit test really is, how to write them, and how to integrate unit tests into existing code.  I'm even considering reading it again.  That says a lot.  I probably won't re-read it, but the fact that I'm considering it is monumental because I never re-read books.

Tags: , , ,