luke.bace (66) [Avatar] Offline
#1
Please post errata here.
jlacar (13) [Avatar] Offline
#2
Re: Errors and Corrections
Chapter 1, first paragraph:

seems like there needs to be a comma between "programming" and "the" in "...started getting paid for programming the world looked..."

Also, while it may just be a matter of preference/style, IMO that first sentence would read better as something like: "When I first started programming, a lot of things were very different from what they are today."

Last sentence: would it be better as "... customer reported that their materials weren't moving as they should." to have consistent tense? "reported" and "aren't" are different tenses. "had reported" seems redundant.
jlacar (13) [Avatar] Offline
#3
Re: Errors and Corrections
Chapter 1, second paragraph:

first sentence: "for most programmer meant" should be "for most programmers meant"

last sentence: mismatch of "you'd" and "can" in "you'd find yourself poking...to see if you can figure..." -- "you would find yourself" should be matched with "to see if you could find..."
jlacar (13) [Avatar] Offline
#4
Re: Errors and Corrections
Chapter 1, third paragraph:

Should be "Automation was a state-of-the-art concept for us." since "state-of-the-art" is used as an adjective for "concept" - see http://wiki.answers.com/Q/Is_state_of_the_art_hyphenated

"...operated our production code and printed out what's happening and what our code is returning..." - tenses are inconsistent: "operated" / "printed" vs. "what is" / "is". Should be "...operated our production code and printed out what was happening and what our code was returning..."
jlacar (13) [Avatar] Offline
#5
Re: Errors and Corrections
Section 1.1 - I don't know if you can really assert that it is a "widely accepted fact" that developers should write automated regression tests. Would it be better to say that "Today, it is widely recommended that developers write automated tests that fail the build when there are regressions."?

Also, is a design really validated by automated tests? Is the criteria for a "valid" design simply one that has all its tests pass? I have seen some poorly designed code that has automated tests that all pass. Is "validity" the right word to use in this context?

Would it be better to say instead that "An increasing number of developers lean on a test-first style of programming as a design aid by specifying the expected behavior in test code before they write the production code."?

I think you need a comma here: "Looking at where we are today, it's clear that automated tests ..." and I think you should remove "such" in the next sentence: "This is good because without (such) automated tests, most software projects would be ..."
jlacar (13) [Avatar] Offline
#6
Re: Errors and Corrections
Section 1.2 - Again, I'm not sure that "accepted fact" is accurate. I would be more inclined to agree with something like "Most developers [readily/easily/quickly/...] understand the benefits of writing automated tests. How many and what kind of tests to write, however, are questions that many still struggle to answer."

I think talking about "benefits" rather than "certainty" would improve this section. You write "We agree that writing some tests is a no-brainer but our certainty decreases as we get closer to full code coverage..." The link between agreeing and having a decreased certainty (in what?) is somewhat tenuous, IMO. It also seems contradictory to say "agree" and "decreased certainty" while asserting that writing tests is an "accepted fact."

These are the salient points you seem to want to make in this section:
* The benefit of writing automated tests is widely understood by developers
* Many developers are uncertain about how many and what kind of tests to write
* The benefits of writing more tests diminish as full code coverage is approached
jlacar (13) [Avatar] Offline
#7
Re: Errors and Corrections
Section 1.2 - Figure 1.1 about diminishing value of additional tests -- wouldn't the line actually start to slope downwards before you reach full code coverage? I know it's supposed to be just a simplified diagram but I think it would help to make your point about diminishing returns to show that there is a point before reaching full code coverage where additional tests may be more trouble than they're worth: more tests to maintain, increased test execution time, possibly redundant test code, etc. Isn't this is why few, if any, developers think that 100% code coverage is necessary or beneficial? Also, would it help to put a vertical line to show where the point of "full test coverage" is reached and that adding tests beyond that is not beneficial either?
jlacar (13) [Avatar] Offline
#8
Re: Errors and Corrections
Further to the question regarding use of automated tests to "validate a design before verifying its implementation," maybe some definitions are in order first. I found this thread that might help clarify the difference between the two: http://elsmar.com/ubb/Forum5/HTML/000015.html
jlacar (13) [Avatar] Offline
#9
Re: Errors and Corrections
Section 1.4.1, page 9, first paragraph. "...and let's us validate..." should be "...and lets us validate..."
jlacar (13) [Avatar] Offline
#10
Re: Errors and Corrections
Section 1.5 - "It's one thing to have tests and it's a whole another thing to have good tests." -- The expression is "a whole 'nother" not "a whole another". See http://en.wiktionary.org/wiki/a_whole_nother -- suggest you use "but it's an entirely different thing to have good tests" instead.

Message was edited by:
jlacar
jlacar (13) [Avatar] Offline
#11
Re: Errors and Corrections
Section 1.3.1 - second to the last paragraph needs restructuring.

In "helping us improve our abilities, awareness and sensibility towards test code's...", our abilities, awareness, and sensibility are independent items that are the objects of the verb "improve" so it should still make sense if you take each separately:

improve our abilities towards code's readability... (doesn't work very well, awkward)

improve our awareness towards code's readability... (works, kind of, but "awareness of code's readability..." is better)

improve our sensibility towards code's readability... (works)

Also, while "towards" and "toward" are both correct, "towards" is apparently preferred in British English while "toward" is preferred in American English. If you're using phrases like "a whole nother" and "a whole lot" then it sounds like you're leaning more toward (grin) American English. See http://www.englishrules.com/writing/2005/toward-or-towards/


Then, the tail end of the paragraph "...reliability, and making sure that we can sustain this way of working with the test code, that is, ensuring its maintainability." -- it's not clear what "this way" refers to... what way? "this way" should refer to a noun phrase but "improve our abilities..." is a verb phrase and so is "ensuring its maintainability."
breilly (2) [Avatar] Offline
#12
Re: Errors and Corrections
In figure 1.4 about TDD (from sample chapter), I think "Revert refactoring" should point back to "Refactor production and test code" instead of "Run all tests" (though it would be a nice loophole if you don't want to refactor production and test code).
boyarsky (63) [Avatar] Offline
#13
Re: Errors and Corrections
In section. "Program's" should be "programs". I fell on this one - the text on principles was very easy to read.
david_wallace_croft (1) [Avatar] Offline
#14
Re: Errors and Corrections
Chapter 4
TWELWE_TIMES instead of TWELVE_TIMES
blush instead of flush

Primitive Assertion makes me think of Java primitives so I get a bit confused. Consider renaming this Cryptic Assertion.

Likewise, Test Doubles makes me think of Java double. At first I did not understand why a whole chapter would be dedicated to testing doubles. Maybe the floating point comparison error? I understand now that Test Doubles has a meaning similar to "stunt double" but on first read as a Java programmer I am initially confused. Something different is needed here. I suppose "Test Doppelganger" might be too Dungeons & Dragons nerdy.

I might have seen definitions of stub and mock objects somewhere that are different from what you have them as. Maybe your fake object is equivalent to what others call a stub and your stub is equivalent to what others call a mock. Maybe.

I get turned off by the Ruby examples as I do not know Ruby and I do not intend to learn it in the foreseeable future. As a result, I gloss over the meaning of the Ruby code and lose some of the context. Perhaps these examples might be more universal with the same effect by using regular expressions?
cyclemaniaque (30) [Avatar] Offline
#15
Re: Errors and Corrections
1.2.2 The curve of design potential

(Last paragraph)
That obviously means that we’re not going to devote much of time and space
for discussing about the aspect of using tests as a design tool.

1) Not sure how obvious this is...
2) Needs rewrite unless I'm reading it incorrectly. Possibly:

Therefore not much time or space will be devoted to discussing the merits of using tests as a design tool.
Moerie (2) [Avatar] Offline
#16
Re: Errors and Corrections
On Page 128 in Listing 5.17

When the runner Parameterized Parameterized takes over it
looks for a no-argument public static void method tagged with the
@Parameters annotation. This method is responsible for returning a list of
parameters – the different variations of the data, including the input as well as
expected output needed by the test.


However, the referenced method is

@Parameters
public static Collection<Object[]> data() {
return asList(new Object[][] { { 1, "I" }, { 2, "II" },
{ 4, "IV" }, { 5, "V" }, { 7, "VII" },
{ 9, "IX" }, { 10, "X" } });
}


which returns Collection<Object[]> so I'm fairly sure "void" should be Collection<Object[]> in the first bolded part.
rmsharp (7) [Avatar] Offline
#17
Re: Errors and Corrections
2.4. Fourth paragraph, last 'sentence' is not a sentence.

Another signal I'm tuning to is how descriptive names do the variables, methods and classes have?
MikB (202) [Avatar] Offline
#18
Section 2.2 meaning structure
Section 2.2, the last sentence of logical page 22 in version 7.
"Imagine that this test we have exercises all of the application’s business logic and behavior through a single monolithic test method that takes half an hour to execute."

does not seem fully comprehensible.

Something like: Imagine that [in] this test we have exercises [for] all of the application’s business logic and behavior through a single monolithic test method that takes half an hour to execute.

OR

Imagine that [] this test exercises all of the application’s business logic and behavior through a single monolithic test method that takes half an hour to execute.

would seem to make this more easy to understand,
MikB (202) [Avatar] Offline
#19
Section 2.4 Sidebar in v7
Section 2.4 Sidebar logical page 27 in v7:
"The general context for the advice of not letting tests depend on each other is that you should let tests in one class to depend on having run tests in another class."

would be be more comprehensible like this for instance;
"The general context for the advice of not letting tests depend on each other is that you should'nt let tests in one class [] depend on having run tests in another class."
MikB (202) [Avatar] Offline
#20
ClassName#methodName?
I'm not familiar of the reference style of ClassName#methodName that I see in Effective Unit Testing. Anyone feel to enlighten me on what is the value of this style of reference compared to "ClassName.methodName()"
MikB (202) [Avatar] Offline
#21
5.8.3 Summary sentence corrections
5.8.3 Summary in 1st paragraph, on logical page 132 in v7:
"The parameterized test pattern is a way to express repetitive test in a compact manner when only differ in terms of input and output values"

needs to be revised and would probably be more clearly expressed with something like:

"The parameterized test pattern is a way to express repetitive tests in a compact manner when the only differences are in terms of input and output values"
dbryant (4) [Avatar] Offline
#22
Re: 5.8.3 Summary sentence corrections
V8 PDF - Page 75, Section 4.8. Cross reference visible in text instead of link to appropriate section

'In Section XREF _405_3371_3766 you learned'

Best wishes,

Daniel
ouapdouap (1) [Avatar] Offline
#23
Re: Errors and Corrections
In the last paragraph of section 4.1.1, page 49 :

Unfortunately we have .... of why we're calculate ...

should be

... of why we're calculating ...

Sebastien
geerkens (1) [Avatar] Offline
#24
Re: Errors and Corrections
Appendix A2
- asserThat ....( see section A2.5 for a ....

wrong refrence, should be A2.2
GDW62 (93) [Avatar] Offline
#25
Re: Errors and Corrections
At the beginning of p205, the last bullet item is:

"- assertThat—Asserts that an object matches the given conditions (see section
A.2.5 for a more thorough explanation)."

Section A.2.5 doesn't exist; it probably should refer to "A.2.2 assertThat() and Hamcrest matchers".
GDW62 (93) [Avatar] Offline
#26
Re: Errors and Corrections
On p211, the first sentence in section B.3.1 "Setting a global timeout" is:

"Remember when we talked about setting a timeout for a test method with @Test(timeout = X)?"

I cannot find where that is mentioned anywhere else in the book.
Wegra (1) [Avatar] Offline
#27
Re: Errors and Corrections
agenda of the chapter 8 is identical to the chapter 6'. Chapter 8 is for using alternative JVM languages for unit testing.

---
In this chapter
􏰀 Test smells around code comments
􏰀 Test smells around poor expectation management
􏰀 Test smells around conditional execution
---