Art of Unit Testing To some, “unit testing” is a four letter word. While it’s unfortunate, the feeling is justified by poor experiences, lack of knowledge, and so on. Personally, I’ve had mixed experiences with unit tests. I’m sure many of you have encountered similar situations. After reading The Art of Unit Testing by Roy Osherove, I feel far more confident in not only understanding unit tests, but also the best practices for implementation. If this book had only been written years ago, maybe all those poor unit testing experiences would have never happened. 

The fundamental thing that I think is most misunderstood about unit testing is simply not understanding what a unit test is. In fact, Roy just recently posted an updated definition of how he would classify a unit test on his blog. Of course a definition isn’t always enough, and in his book, Roy starts off by fully explaining all the aspects of what a unit test should be and the basic outline for how to succeed. I would highly recommend that you visit his book’s webpage (http://manning.com/osherove/) and download the sample first chapter. 

This seriously may be the best book ever written on unit testing. I understand that “the best” is a strong statement, but this book is really the perfect package. Let’s look at what makes this such a winner…

Come On, The “Best”

Of course, don’t just take my (or BOO’s, or Tim’s) word for it. Obviously, check out other’s reviews on Amazon as well. However, there are many points that justify my opinion:

  • No Fluff - It’s a slimmer book (320 pages), but packed with information. The size of the book makes it very approachable, and it’s one of those books that you may want to read a few times to make sure everything really sinks in. It’s a book you can recommend to just about everyone, regardless of their background.
  • No Preaching - One key thing that sets this book in a class by itself is the fact that it doesn’t focus on specific methodologies (like TDD), but is simply a guide to unit testing. The book doesn’t assume anything or force any one way of practicing the art. Fully devoted to TDD, great. Could care less about TDD? This book is for you as well.
  • Independent – Despite the fact that Roy works for Typemock, the majority of examples found in the book use open-source “mocking” or isolation frameworks. Throughout the book, no one tool is pushed over another. Roy does a good job of going over the pros and cons of many different tools, from many vendors.
  • Inspiring - From the initial chapter on, this book not only educates, but it truly inspires. This is one of those books that gets you ramped up to do something. Whether it is starting unit testing within your organization, or enhancing existing tests, you’ll want to start right away. It’s that feeling we geeks get when a new version of software is released. I know I’m not the only one who goes to software conferences and such, and feels like jumping head first into the latest and greatest. 

Chapters

This is one of the few books where each chapter matters. Even the appendices are packed with important information. You can see overviews of each chapter anywhere, so I won’t bore you with every little detail here. But a few of the chapters really stood out.

  • Chapter 4, Interaction testing using mock objects – We’ve all heard the terms “mocks” and “stubs,” but do you know the difference? Many books refer to these, but the terminology can be confusing. After Chapter 4, you’ll have a good grip on what’s what. The explanations and best practices in this chapter, set the base line for the rest of the chapters. It would be nice if everyone could use the “common” definitions of things, but unfortunately, this practice isn’t always followed when it comes to discussions of unit testing. 
  • Chapter 8, Integrating unit testing into the organization - This topic in and of itself could be described as an “art.”  You may believe in something, but conveying the belief to others isn’t your typical walk in the park. I was very impressed that this important issue was covered in the book. 
  • Chapter 9, Working with legacy code – Of course we can’t always be working on brand new development. This chapter gives a good introduction and solid approaches for dealing with legacy code. This is another one of those chapters that’s refreshing to see within a  book of this nature. I like how the book branched out into topics that aren’t frequently discussed. However, this topic is really one of those that could use an entire book written about it, and Roy recommends Michael Feathers, Working Effectively with Legacy Code. Gag, legacy code, right? It’s a reality, and remember, that new shiny thing your working on will most likely end up as someone’s headache soon enough!

More From Roy

After reading his book, I immediately started seeing what else Roy has been up to. There are two great resources that Roy started, 5whys.com and the Team Leadership in Software group on Google. Both will help you in working with and leading software teams. On the unit testing/TDD front, be sure to check out Roy’s videos. You can also check out Roy’s other sites, http://osherove.com/, http://iserializable.com/, and http://artofunittesting.com/.