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.
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.
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.
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.
The text says that “the assertThat syntax introduced in JUnit 4.” That API was actually introduced in version 4.4, not 4.0.
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 187, section 9.2.7, section title
Page 189, DISABLING LOGGING WITH A LITTLE CLASS PATH TRICKERY, in section title and twice in section text
Page 200, next to last paragraph
Later versions of JUnit come with a built-in
org.junit.rules.TemporaryFolder that could be used for the very same thing we're trying to achieve in section 5.5.2.
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.
The chapter opening ("In this chapter") begins with an outline of chapter 6, not chapter 8. The three-bullet list should instead say:
Using multiple programming languages on the JVM
Achieving conciseness in test code with a dynamic language
Added expressiveness with behavior driven development frameworks
The last bullet should reference section A.2.2, “assertThat() and Hamcrest matchers.”
The section begins with a reference to a passage that was removed from the manuscript:Remember when we talked about setting a timeout for a test method with
@Test(timeout = X)?
The printed manuscript doesn’t actually talk about such a thing so please ignore that mention. We’ll remove that sentence from the next printing.