On the night of June 10, 2009, I found an email in my inbox from Christina Rudloff from Manning, asking me if I knew anyone who might be a good candidate to write a Java edition of Roy Osherove’s book, The Art of Unit Testing in .NET. I told her I’d do it.

That was a long time ago and what you’re looking at right now has very little in common with Roy’s book. Let me explain.

The project started as a straight translation from .NET to Java, only rewriting where necessary to match the changing technology platform, its tooling, and its audience. I finished the first chapter, the second chapter, the third chapter, and suddenly I found myself rewriting not just short passages but entire chapters. The tone of voice wasn’t mine; sometimes I would disagree or have preferences incompatible with Roy’s, and sometimes I simply felt strongly about saying something, setting things straight, and putting a stake into the ground.

Eventually, I decided to start over.

It was clear that we were not in a translation project. This was a brand new title of its own—a book that helps a Java programmer improve his tests, gaining a deeper insight into what makes a test good and what kind of pitfalls to look out for. You can still see Roy’s thinking in many ways in this book. For instance, the chapter titles of the catalog in part 2 I’ve blatantly borrowed from Roy and chapter 7 was written largely thanks to Roy’s counterpart in The Art of Unit Testing in .NET.

This is a book for the Java programmer. Yet, I didn’t want to straitjacket the ideas in this book artificially, so I tried to steer away from being too language-specific even though all of the code examples in the pattern catalog, for example, are Java. Writing good tests is a language-agnostic problem and I heartily recommend you read this book thoughtfully, even if you happen to spend most of your office hours hacking on another programming language.

Along those same lines, I didn’t want to give you a tutorial on JUnit or my favorite mock object library. Aside from such technology being a constantly changing landscape and bound to become stale information within months of publication, I wanted to write the kind of book that I would want to read. I like focused books that don’t force me to lug around dead weight about a testing framework I already know by heart or a mock object library I don’t use. For these reasons, I’ve tried to minimize the amount of technology-specific advice. There is some but I want you to know that I’ve done my best to keep it to a minimum—just enough to have meaningful conversations about the underlying concepts that I find essential in writing, running, maintaining, and improving tests.

I tried to write the book I would’ve wanted to read. I hope you will enjoy it and, most importantly, integrate some of these ideas into your own practice.