Deal of the Day

Home » Main » Manning Forums » 2009 » Effective Unit Testing

Thread: Errors and Corrections

Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 26 - Pages: 2 [ 1 2 | Next ] - Last Post: Aug 9, 2013 5:57 AM by: Wegra
luke.bace

Posts: 66
Registered: 7/7/09
Errors and Corrections
Posted: Jan 4, 2011 10:27 PM
  Click to reply to this thread Reply

Please post errata here.

jlacar

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 22, 2011 10:11 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 22, 2011 10:29 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 22, 2011 10:40 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 22, 2011 11:35 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 23, 2011 7:47 AM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 23, 2011 8:12 AM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 24, 2011 2:47 PM   in response to: jlacar in response to: jlacar
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 24, 2011 7:06 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

Section 1.4.1, page 9, first paragraph. "...and let's us validate..." should be "...and lets us validate..."

jlacar

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 24, 2011 7:18 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 12
From: Buckeye Country
Registered: 4/22/11
Re: Errors and Corrections
Posted: Apr 24, 2011 7:57 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 2
From: Boston, MA
Registered: 5/10/11
Re: Errors and Corrections
Posted: Jun 9, 2011 8:53 AM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 62
Registered: 2/19/07
Re: Errors and Corrections
Posted: Oct 8, 2011 3:59 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

In section. "Program's" should be "programs". I fell on this one - the text on principles was very easy to read.

david_wallace_c...

Posts: 1
From: Dallas
Registered: 3/7/12
Re: Errors and Corrections
Posted: Mar 7, 2012 1:29 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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

Posts: 31
From: Hillsboro, OR
Registered: 9/30/09
Re: Errors and Corrections
Posted: Mar 8, 2012 5:01 PM   in response to: luke.bace in response to: luke.bace
  Click to reply to this thread Reply

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.

Legend
Gold: 300 + pts
Silver: 100 - 299 pts
Bronze: 25 - 99 pts
Manning Author
Manning Staff
Manning Developmental Editor