Effective Unit Testing

Errata

Hello! This is a collection of errors in the printed copies of Effective Unit Testing. If you find any errors that aren't listed below, or if you find a passage that isn't explained well, we’d appreciate hearing about it! Please post errors and suggestions in the book’s Author Online Forum. We'll publish them here for everyone’s benefit. Thanks!

First printing

Page 4, section 1.1

The section begins with a somewhat bold statement:

Today, it’s a widely accepted fact that developers should write automated tests that fail the build if they find regressions.

Perhaps it’s too bold to claim that it’s a “fact”. Please interpret the sentence more along these lines:

Today, it’s widely recommended that developers write automated tests that fail the build when there are regressions.

Page 7, first paragraph (section 1.2)

In line with the above change, let’s rephrase this related passage as well:

Earlier I suggested that it’s widely accepted that developers should write automated tests. What’s much less widely accepted is how many and what kind of tests to write.

...and instead word it like this:

Most developers readily understand the benefits of writing automated tests. How many and what kind of tests to write are questions that many still struggle to answer.

Page 7, second paragraph (section 1.2)

There's a paragraph that reads:

So what can we make of this? We agree that writing some tests is a no-brainer, but our certainty decreases as we get closer to full code coverage—we’ve written tests for pretty much everything and the remaining code without any tests is almost too trivial to break. This is what some folks call a diminishing return and it’s often visualized with a curve similar to figure 1.1.

In an attempt to achieve better clarity, let's reword as follows:

So what can we make of this? Most of us agree that writing some tests is a no-brainer. However, the closer we get to full code coverage, the fewer of us would agree that aiming for such a volume of tests is obviously a good idea. This is what some folks call a diminishing return and it’s often visualized with a curve similar to figure 1.1.

Page 9, second-to-last paragraph (section 1.2.1)

This paragraph has a passage in need of better grammar and clarity:

This is also the stuff that most of the rest of this book will revolve around—helping you improve your abilities, awareness, and sensibility toward test code’s readability, trustworthiness, and reliability, and making sure that you can sustain this way of working with the test code—ensuring its maintainability.

Here's an improved version:

This is also the stuff that most of the rest of this book will revolve around—helping you improve your awareness of and your sensibility toward the test code’s readability, trustworthiness, and reliability, and making sure that you can sustain your way of working with the test code by ensuring its maintainability.

Page 49, second paragraph in section 4.1.2

The text says that “the assertThat syntax introduced in JUnit 4”. That API was actually introduced in version 4.4, not 4.0.

Page 69, note

Two instances of the term “class path,” which should be one word: “classpath.” This same error appears several more times in the book:

Page 90, section 5.4.2, two instances

Page 189, DISABLING LOGGING WITH A LITTLE CLASS PATH TRICKERY, in section title and twice in section text

Page 200, next to last paragraph

Page 92, section 5.5.2

Later versions of JUnit come with a built-in @Rule called org.junit.rules.TemporaryFolder that could be used for the very same thing we're trying to achieve in section 5.5.2.

Page 104, section 5.8.1

Below Listing 5.17 there’s a reference to the signature of a @Parameters annotated method. The method’s return type isn't void like the text suggests but Collection<Object[]> as shown in Listing 5.17.

Page 156, chapter 8 opening

The chapter opening ("In this chapter") begins with an outline of chapter 6, not chapter 8. The three-bullet list should instead say: