Historical errata for Modern C++ Programming with Test-Driven Development

Hi,

There is a link provided to one of the author’s websites “agileinaflash.com”

However, the link also contains the ending “.”, so I received a “bad hostname” error when clicking on the link — attempting to open it in FireFox. The URL appears as “agileinaflash.com.” If the period just gets moved over, things should be perfect :)

Take care!

Travis

Section 2.3, Paragraph 2 says “…Rule #4 seems simple, but
the word “continue” suggests that it builds atop the first three rules…"

The “Rule #4” it alludes to is from the SOUNDEX Algorithm Definition. The author says…
“4. Stop when you have a letter and three digits. Zero-pad if needed.”

It has no “continue” in it.

Thanks!

Travis

Last paragraph of page vi in the intro:
“How can you preventing these challenges
from derailing your transition effort?”
- preventing should be prevent?

duplicate:
A number of the examples use third-party, freely-available libraries. Refer to
3rd-Party Libraries
Some of the examples use freely-available third-party libraries.

Great stuff! Hopefully the next edition will include a draft of the “Global Setup” chapter — I’m ready to get rolling but don’t have the environment ready.

In section 2.5,

“However, taking small steps will increase your spead over time…”

‘spead’ should be ‘speed’.

End of 2nd paragraph: “naming standard.)” has a spurious closing paren.

Naming conventions for the trailing underscore: why this particular convention?

At the end of section 2.6, there were two example tests; at the end of section 2.7, a third test ReplacesConsonantsWithAppropriateDigits) appears without discussion.

This should be just “diacrtics” not “diacriticals” (or it could also be “diacritical marks”).

“Our isVowel() function needs to support vowels with diacriticals.”

This sentence is a bit unclear:
“If you’re worried about nefarious other programmers abusing the relaxed access, don’t.” …. do you mean “dont worry” or “dont relax the access”?

Para 3: add the word ‘test’ to: “We run the tests, but our new [test] does not pass”

Obviously there are many ways of thinking about what to code as a solution. Harking back to your comments on pages 8-10, the “simplest” thing I could think of to get the test to pass was another hard-coded example:
if(word == “Ab”) {
return “A100”;
}
… before refactoring, of course. Seems as if you’re now taking bigger, not quite so simple, steps than you were discussing very pointedly in the first few pages of the book; therefore it might be worth commenting on this before proceeding.

Section “Thinking and TDD”, paragraph 2: Change “…TDD cycle, you be able to must answer” to “…TDD cycle, you must be able to answer”.

in the code snippet, 3rd function should be “std::string createCommand…” instead of “std::createCommand…”

in snippet “c5/2/PlaceDescriptionServiceTest.cpp”:
stringutil::ticToQuote is not necessary. The same can be achieved with raw string literals.

—
(The ticToQuote() method converts single quotes (tics) to double quotes. That prevents us from having to escape scads of embedded double quotes with backslashes.)

The first time that zeroPad() is introduced, it wasn’t clear to me whether it should go in the public or the private section (later code listings clear the matter up).

2.6 and other parts in the chapter, sometimes when you show an excerpt I’m not sure how I’m supposed to be modifying the code. I.e. when you add:

class SoundexEncoding : public Test {
public:
Soundex soundex_;
};

I wasn’t sure where this had to go as the code listing looked complete, yet didn’t include the Soundex class itself.

This is in the code listing at 2.7 before it’s introduced:

TEST_F(SoundexEncoding, ReplacesConsonantsWithAppropriateDigits) {

ASSERT_THAT(soundex_.encode(“Ab”), Eq(“A100”));

}

Was I supposed to put “#include ” beforehand? My code was compiling without it… :S

2.10, the first code listing does not match with the following text and code listing.

“TEST_F(SoundexEncoding, CombinesDuplicateEncodings) {
ASSERT_THAT(soundex_.encode(”Abfcgdt“), Eq(”A123"));
}

Hm? That’s a confusing test! To understand why Ajcdl encodes to A234, we have to understand that j and c both encode to 2."

Near the bottom of the page: “A bit of code analysis tells us that encodeDigit() returns null when its map doesn’t contain the requested character. Code in the encodeDigits()”

Should probably be “encodedDigit() / encodedDigits()” since that’s what we called these methods in the code.

Just curious why we need the static_cast in this code:

char upper(const char& c) const {
return static_cast(::toupper©);
}

Maybe a quick sentence or two in the book would help for those on the less experience side? ;)

The last changes before 2.12 break the test case “SoundexEncoding.IgnoresVowelLikeLetters”.

“However, taking small steps will increase your spead” <- “speed”

paragraph 3
Reads: “Google Test prints a [ RUN ] record with each test name when it starts, and a [ FAILED ] or [ PASSED ] bookend when the test fails.”
Problem: Should read something like “Google Test prints a [ RUN ] record with each test name when it starts, and a [ FAILED ] or [ OK ] bookend when the test ends.”

In program listing, last test ReplacesConsonantsWithAppropriateDigits not mentioned before in text. Remove.

program listing c2/13/SoundexTest.cpp
const std::string head(…
and
const std::string encodedDigits(…

should be

std::string head(…
and
std::string encodedDigits(…

Reason: const-ing the return value does not protect the user for inadvertently changing the result, even with auto. The reader might think so. And it’s less text to read. Plus it’s consistent with encode and zeroPad.

program listing c2/15/SoundexTest.cpp (last)
const std::string encodedDigits(…
should be
std::string encodedDigits(…

for same reason as PDF page 17.

#include is not mentioned before but is used in the “production” code. Now #include

const std::string encodedDigits(… , mentioned twice
and
const std::string tail(…

remove const as per motivation on pdf page 17 suggestion.

last listing c2/21/SoundexTest.cpp
I get a compiler warning with gcc 4.7.2:
../SoundexTest.cpp:120:1: required from here
/home/bo/workspace/gmock/include/gmock/gmock-matchers.h:801:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

Solved this by changing Eq(4) to Eq(4u).

On p.64 it says:

“As a reminder of what the test case name is, the following test declaration has a test case name of IncrementsSizeWhenTweetAdded.)
TEST (ARetweetCollection, IncrementsSizeWhenTweetAdded)”

It then says:

“In Google Test, you define a fixture as a class derived from ::testing::Test. You typically define the fixture at the beginning of your test file.
using namespace ::testing;
class ARetweetCollection: public Test {
};”

On page 65 it says:

“The test case name must match the fixture name!”

This implies that the test case name is actually ARetweetCollection? This is a bit confusing.

ASSERT_THAT(actual, ::testing::StartsWith(“al”));

…

ASSERT_THAT(tweetsAdded, Eq(3));
.. the failure message tells you what the assertion expected plus what was actually received:
Value of: tweetsAdded
Expected: is equal to 3
Actual: 5 (of type unsigned int)
The wording of the failure message is why you always want to specify the expected value as the first argument to the assertion and the actual value (of what you’re verifying) as the second argument.

Given the example before, I think you mean to say you always want to specify the actual value as the first argument and the expected as the second?

TEST (ATweet, RequiresUserNameToStartWithAnAtSign) { string invalidUser(“notStartingWith@”);
try {
Tweet tweet(“msg”, invalidUser);
} catch (const InvalidUserException& expected) {}
}

Is this missing a call to “fail()” after the call to “Tweet tweet(…)” ?

“… increase your spead over time …”

c2/27/SoundexTest.cpp regarding the new upper-method

Should have interface “char upper(char c) const”. const reference of chars just causes overhead and is inconsistent with encodedDigit-method.

Also a note on the implementation. Consider
return std::toupper(static_cast©);
and add #include

OR
return ::toupper(static_cast©)
and add #include <ctype.h>

With <ctype.h> you know you have access to ::toupper, but can have access to std::toupper.
With you know you have access to std::toupper, but can have access to ::toupper.

The casting is needed since if c is not an unsigned char value, or EOF, the behavior is undefined. Some locales might have difficulty separating 0xFF from –1 (EOF).

c2/30/SoundexTest.cpp
The change to encodedDigit-method, consider implementing a lower-method and using it instead of ::tolower since we already have upper or cut both upper/lower-methods out for consistency. Whatever you choose, be consistent with the <ctype.h> or include you use as my comment on PDF page 27.

See my remark on PDF page 30. This is were it goes :-)o

To clarify #51202

The code sample is not incorrect, but once you implement the functionality for CombinesDuplicateCodesWhen2ndLetterDuplicates1st it breaks IgnoresVowelLikeLetters. The expected output for IgnoresVowelLikeLetters needs to be updated to “C340”

Now to follow up on #51256, once you’ve implemented DoesNotCombineDuplicateEncodingsSeparatedByVowels in 2.13 the expected result of IgnoreVowelLikeLetters is once again “C234”

“The ASSERT_ANY_THROW macro fails the test if the expression it encloses throws an exception.” - it should fail if the express does not throw an exception

“Passing a reference would give us a slicing problem”. References are just syntactic sugar for pointers, so you can choose to use either one.

2.9 Dropping Vowels
When adding TEST_F(SoundexEncoding, IgnoresVowelLikeLetters) the code already in place DOES NOT FAIL. Thus the changes are not motiviated. I checked this with the code in c2/22/SoundexTest.cpp and added the test. It, too, does not fail when adding the test.

Bottom om page reads:

loop in toDigits() to start at 1, not 0.

should be

loop in encodedDigits() to start at 1, not 0.

Change test TEST_F(SoundexEncoding, IgnoresVowelLikeLetters)
from

ASSERT_THAT(soundex_.encode(“CAaEeIiOoUuHhYycdl”), Eq(“C234”));

to

ASSERT_THAT(soundex_.encode(“BAaEeIiOoUuHhYycdl”), Eq(“B234”));

it WILL break at the end of 2.11 on page 38. I believe you handle the problem with keeping a consonant when there are vowels inbetween later on.

Method isVowel uses ::tolower, should use lower-method instead and read
return std::string(“aeiouy”).find(lower(letter)) != std::string::npos;

Remove #include . Not used anywhere in the code.

std::string createCommand(const std::string name) const
should take a const reference as argument, not copy by value.

Consider always nulling pointers you delete. It’ll easier pick any wrong doings in the test code.
void TearDown() {
delete tweet; tweet = nullptr;
}

RAII is not defined — it would probably be helpful for less-experienced C users or users coming from other languages like Java or C# to define what RAII is, how it works with scope and the stack, and what its advantages are.

Missing a space after the period, and “Unintentially” should be “Unintentionally”:

“correct order.Unintentially”

(Error in Extract “Introduction”)
Page 13: Link to agileinaflash.com is not valid.

Trailing in line
./test —gtest_filter=Retweet.:ATweet.:-ATweet*.Construct

Boost is a heavy dependency to download and install for the wave reader project. Also, I wasn’t able to get rlog to build on OS X Mountain Lion. It would be nice to be able to follow this project without having these extra dependencies.

If the format specifiers for rlog are following printf, then they should be adjusted:

“riff header size = %lu”
“subchunk header size = %lu”
“data length = %u”

Based on compiler warnings from llvm.

After adding WavReader::dataLength, the code does not compile because the book does not mention that a declaration will also need to be added to the header file.

Should explain what a “slicing” problem is — this isn’t something encountered in other languages like Java, where everything is a reference.

First paragraph… In the e-book, I suggest making the phrase “Tiobe index of programming language popularity” a link so readers can see the current standing.

“Unfortunately, JsonCpp requirea Scons”
should be “Unfortunately, JsonCpp requires Scons”

“It also does not support all platforms due to little/big endian differences.”

Will this be addressed?

NickMock mentioned twice. NiceMock is intended.

Not sure if this is a typo, or if I’m just not understanding something:

In section 3.7 Mechanics for Success

test name MustConstructWithTableMetadata
implementation return member variable from accessor

The following reference to “test file” confused me, and I don’t think the “Setup and Teardown” section even mentions more than one test file per class:

“Good reasons exist to have more than one test file per class—don’t ever feel
constrained to only one. Read Setup and Teardown,on page 75 to understand
when you might want more than one test file per class.”

I assume you are saying that (assuming gtest) it wouldn’t be unusual to have multiple classes that derive from testing::test — each declared and implemented in a separate file — and all such classes testing the same SUT.

Maybe this is nit-picking. You write:

“Given—When—Then: Given a context, when the test invokes some behavior, then some result is verified.”

I think you should say something along the lines of, “When the test invokes some SUT API (s), then some behavior is verified.”

Re: 51681.

In fact you do expressly indicate that the test verifies behavior in the very next sentence and paragraph:

"… an understanding of
the behavior your test verifies.) … your focus when doing TDD is on verifying behavior, not executing tests.

“You’ll learn how to begin breaking those dependencies on slow collaborators
in Test Doubles on mocks.”

“You’ll learn about different ways of setting up your code so
that it can use test doubles (also know as injection techniques.”

know -> known
. -> ).

You write,
“In some circumstances, you might find it more appropriate to pass the test double using a setter member function. Injecting a test double in this manner is known as (what else?) constructor injection or setter injection.”

Suggest the last sentence be re-written something like, “These alternative ways to inject a test double are known as . . .”

I’d bet that the virtual destructor was cut-and-paste from before the class was made into a template and that you didn’t really mean it:

virtual ~PlaceDescriptionServiceTemplate() {}

You sum up 4 paragraphs of bad outcomes with the following:

“The lesson I learned: Bad dependencies in tests can create significant problems, just as can bad
dependencies in production code. But in hindsight, the inadequate system design was a far
larger problem than the excessive mocking.”

Your conclusion seems (to me) to be impossible to reach given the information provided in the preceding 4 paragraphs. Maybe you should add some more context or explanation.

The
highly-regarded book, Growing Object-Oriented Software, Guided by Tests
[FP09] by Freeman and Nat Pryce, focuses on using TDD to grown out a system
in this manner.

grown out -> grow out? (flesh out, incrementally grow, build?)

Let’s work through developing a small subsystem
and see how Beck’s notion of simple design plays out.
You write,

"Story: Portfolio Manager
Investors want to track stock purchases and sales, to provide the basis for financial analysis.

We’ll take a look momentarily at a starter set of code for this story, right after
you’re clear on why eliminating duplication is so important."

To say we’re going to work through developing and to provide the Story — then to switch gears and bring in a new document section — was kind of jarring and didn’t make sense to me.

TDD supports incremental and iterative developmenet through its core cycle
of specify, build, refactor, repeat.

developmenet -> development

Some elements don’t belong in tests at are.

are -> all

Our customer has asked us to resolve of
these limitations (leaving the rest to you for future incorporation).

resolve of -> resolve all of

It seemed quicker at first, but the lack of tests
quickly burned past any time saved as I fell into a couple defect weed patches.)

couple defect -> couple of defect

TEST_GROUP(WavReader) {
};

Shouldn’t this be TEST_GROUP(WaveReader_WriteSamples){…}?

I got really lost with what you mean here (among other things, the name ‘execute’ does nothing for me):

“The size() function defined on FileUtil would create an ifstream, then pass it to the StreamUtil size(). You might consider this function to be so small as to not break, and consider not writing a unit test for it. Better: Create a single FileUtil function execute() that passes the ifstream to a function object. Client code would pass an appropriate function; for example: …”

You can read extensively about the technique in .

The Mikado Method book ()
will supply you with everything you’ll want to know.

The second test for the Work class, CanExecuteOnDataCapturedWithFunction,
merely shows how lambdas work and is technically not necessary.

second -> last

Also, is the next to last test also not technically necessary?

The challenge with an asynchronous call is that may complete long before
the work gets executed.

that may -> that it may

unsigned int NumberOfWorkItems{10};
unsigned int NumberOfThreads{10};
for (unsigned int i{0}; i < NumberOfWorkItems; i)
threads.push_back(
make_shared([&] {
for (unsigned int j{0}; j < NumberOfWorkItems; j)
pool.add(work);
}));

NumberOfWorkItems -> NumberOfThreads in the outer loop

To find
the remaining problems, one analysis tactic is to think about any “gaps” we
have—where we make an assumption about a fact that might no longer be
true, due to the actions of other obstreperous threads.

Last comma is extraneous (sorry to be pedantic, but I had to say it after reading about ‘obstreperous’ threads).

Unfortunately, this test has the potential to fail, on the rare occasion that
one of the threads processes all of the work items.

See? Once you let one extraneous comma in, they start showing up everywhere. Last comma is unwelcome.

Following the TPP
allows you to grow your system using the smallest possibly increments.

possibly -> possible

Introducing that code would represent the transform (unconditional→if), which is just a bit further down in priority than (constant→scalar):

Suggest you conclude this sentence with:

, so we choose the higher priority constant->scalar transform:

This is probably a topic for some discussion forum, but I add it here as a reminder:

std::string encode(const std::string& word) const {
➤ std::string code(“”);
➤ code += word[0];
➤ if (word[1])
➤ code += “100”;
➤ else
➤ code += “000”;
➤ return code;
}

The above code and that in the next few iterations seem to assume the a std::string is like a null-terminated c-string. But std::string is not by default null-terminated. E.g., std::string s(“abc”); has no ‘\\0’ character.

1 - don’t know how your early tests worked

2 - the later refactoring’s removed the null-termination assumptions, so I guess all’s well that ends well. But you might consider devoting some commentary to this in the book text.

In later versions of the TPL, you’ll find slight variations on the ordered.

ordered -> order??

That
transformation to a recursive solution is of slightly higher priority than
transforming to a while loop has been a topic of debate.

That -> The fact that??

First, a fabricated conversation will prepare you for typical questions,
by providing some brief but strong elevator-pitch answers.

Extraneous trailing comma.

In a code base growing to a large size over time, things that
might have take a couple hours to accomplish can bloat to taking several days.

take -> taken

Hopefully, you’ve learned in this book that TDD requires you to constrain the scope of each test, so that it tests a small piece of isolated logic.

Extraneous trailing comma.

You and your team must actively seek to squash poor design, in both the tests and the code.

Either extraneous trailing comma, or you really wanted:

You and your team must actively seek to squash
poor design — in both the tests and the code.

You might even
find

…

Extracting a common function would work to eliminate the duplication,
but seems less than stellar since two separate elements are changing
(the Arabic total and the Roman string).

Either extraneous trailing comma or —

“less wasted for developers” => “less wasted TIME for developers”

“a single-line declarative assert that ensure an exception is thrown” => “… ensures …”

“you’re read to tackle” => “you’re ready to tackle”

Aloha. First of all, AWESOME BOOK. I have been dying for this exact book for years. Thank you! I love that the information is distilled and there is almost no filler. That being said, I’m an experienced programmer but have never used Google’s Test or Mock before, nor have I used testing libraries that cannot be installed system-wide, i.e. with `make install`. For that matter I haven’t previously done testing with frameworks, hence my insta-purchase of this book. Anyways, Google Test/Google Mock doesn’t behave this way and it took some Googling and reading (and thinking) on my part to understand this. The pages and tutorials on Google Code do not explicitly mention this. While another page of installation instructions would be burdensome, I think it would be very helpful to inexperienced readers if you include a small paragraph in the GoogleMock/Test setup section explicitly mentioning that the libraries cannot be precompiled for system-wide access, that the framework must be specified as compiler/linker flags/options during the same compilation as those of the tests we are writing. Something like that would have saved a good eight hours of evening/weekend time. That sounds ridiculous, I know, but like I said this is my first time testing in C and with a framework that can’t be installed system-wide. Aloha and thanks again for the incredible book! I can’t wait to get the printed edition into my hands!

The text at the end of section 1.8 refers to the libjson shared library (.so), but the instructions describe linking to the archive file.

Use unsigned numeric constants when assigning or comparing with unsigned values in the code. Replace all code example 0:os with 0u. (or 0U). Five places. First one also causes a compiler warning. ASSERT_THAT(collection.size(), Eq(0u));

Use unsigned numeric constants when assigning or comparing with unsigned values in the code. Replace all code example 1:s with 1u. (or 1U). Two places. Last one also causes a compiler warning. ASSERT_THAT(collection.size(), Eq(1u));

For consistency with page 57 and 58
“return 0;” to “return 0u;”
and
“return isEmpty() ? 0 : 1;” to “return isEmpty() ? 0u : 1u;”

… now encodes the entier word…

Top of page reads “…for some proposed C++14 features
proposed.” Drop last `proposed’.

I couldn’t find OutParameterTest.cpp in the repo, but the sample in the book appears to be incorrect. Here is an updated version:

DifficultCollaboratorMock difficult;
EXPECT_CALL(difficult, calculate(_))
.WillOnce(DoAll(
SetArgPointee<0>(3),
Return(true)));
int target;

auto result = difficult.calculate(&target); // ignore return value in this test?

ASSERT_THAT(target, Eq(3));

“You must take advantage of the opportunity that each a passing test provides you”

“Immediate understanding disappers…”

“softare design.”

“which would involved changing existing”

To install CppUTest, ‘./configure’ need before ‘make’. and ‘make’ also builds CppUTestExt. ‘make install’ copies the library to common path ‘/usr/local/lib’

—- before —-
cd $CPPUTEST_HOME
make
make -f Makefile_CppUTestExt

—- suggestion —-
cd $CPPUTEST_HOME
./configure
make
make install

scons script has permission to excute. I tested Mac and Linux platform, Just ‘scons platform=linux-gcc’ makes success. - But ‘python scons platform=linux-gcc’ doesn’t work.

—- before —-
python scons platform=linux-gcc

—- suggestion —-
scons platform=linux-gcc

In ThreadPoolTest one lock call uses std:: and one does not

“so none of its lines is highlighted”

On page, 86 of Beta version 5, there is the following sentence : “The concept of AAA won’t shatter any earths, …”. However, I believe the author is trying to use the English phrase, “The concept of AAA isn’t earth shattering, …”

RLog installation for OSX are not working.

- the diff file does not exist in the source code specified folder (I manually diffed though)
- atutoreconf command is not working

any suggestions?

Thank you
Sherief

Pet peeve of mind…

Prefer forward declarations to including header files. In section 6.1 in Portfolio.h just forward declare std::string and include in Portfolio.cpp.

From “C Programming Standards: 101 Rules, Guidelines, and Best Practices” rule 22.

P.S. Reading this on my Kindle (no page numbers in Kindle, just 4782 of 11562 (41% of the way through the book).

work “flesh” is used in few places, I think you mean “flush” there

In my comment “#52372: work” I mean “word” , sorry for my typo.

I have completed upto 5 chapters now and I wanted to point out that you are using web related examples, I was expecting some other examples as C programmers work more towards system side and Java programmers can deal with web related stuff.

Can you please give a better name to shares_
It does not describe what it is?
It could be numOfShares…

Please remove trailing spaces from source code files.

Shares() is the function name.
The meaning is not clear from its name.
It should be getNumOfShares() atleast to be clear.

Can you please change names in below function
Sell(const std::string& symbol, unsigned int shares)

symbol ———-> symbolOfShare
shares ———-> numOfSharesToSell or numOfShare

This is just a suggestion.

This is not how to use allay.

“The test serves to allay our still-growing knowledge of how to use lambdas” -> “allay uncertainty about”

“changebar” triangle missing left of return statement for

unsigned int size() const {
return size_;
}

ASSERT_THAT(collection.size(), Eq(1)); should use unsigned 1 to avoid compiler warning with gcc.

ASSERT_THAT(collection.size(), Eq(1u));

Second last line should read
ASSERT_THAT(collection.size(), Eq(0u));
to avoid compiler warning.

Change ASSERT_THAT(collection.size(), Eq(0));
to ASSERT_THAT(collection.size(), Eq(0u));
to avoid compiler warning.

Change ASSERT_THAT(collection, HasSize(0));
to ASSERT_THAT(collection, HasSize(0u)); avoids compiler warning.

“The MATCHER_P macro in Google Test defines…”
should read “The MATCHER_P macro in Google Mock defines…”.

Both Eq(0) and Gt(0) should read Eq(0u) and Gt(0u) to avoid compiler warning.

Change ASSERT_THAT(collection.size(), Eq(1)); to ASSERT_THAT(collection.size(), Eq(1u)); to avoid compiler warning.

Bottom of page: “Decide on a naming scheme, such as BehaviorDescriptionTest or TestBehaviorDescription or BehaviorDescriptionTests.cpp.” Sentence is a bit confusing reading it quickly.

Suggest adding .cpp on all schemes or leaving it out on all.
Move the first and third scheme closer to easier see you playing with ‘…Test’ and ‘…Tests’.

“Google Mock” mentioned twice on page, but should read “Google Test” since fixtures are part of Google Test and not Google Mock.

“Google Mock” (mentioned three times) to be replace with “Google Test” since fixtures are part of the Google Test framework and not Google Mock.

ASSERT_THAT(collection.size(), Eq(1)); (used twice) should be ASSERT_THAT(collection.size(), Eq(1u)); to avoid compiler warning.

Last paragraph on page “(Google Mock… ” should read (Google Test… " since this is part for the basic Google Test functionality.

Top of page, replacing “ASSERT_THAT(collection.size(), Eq(1));” with “ASSERT_THAT(collection.size(), Eq(1u));” takes care of compiler warning.

Using ASSERT_THAT(collection.size(), Eq(1u)); instead of ASSERT_THAT(collection.size(), Eq(1)); avoids compiler warning.

Replace “Goole Mock” with “Google Test”. gtest handles the filtering.

Four times “Google Mock” to be replaced by “Google Test”. This is gtest functionality.

Google Mock to be replaced by Google Test.

Google Mock to be replaced by Google Test. (Last comment just refered to wrong page. Sorry for the spam.)

“ASSERT_EQUALS()” should be “ASSERT_EQ()” found on last line before heading “Comparing Floats”

Possibly stick to the Hamcrest notation for comparing floats. I.e., show ASSERT_THAT(x - y, FloatEq(9.9)) and ASSERT_THAT(x - y, FloatNear(9.9, 0.05));

Also, if you want to expand you can mention one reason ASSERT_EQ(x-y, 9.9) doesn’t work is 9.9 is double. Had you written 9.9f, which is a float, the strange fail might go away.

On OS X Mavericks DP6 I had to ‘#import ’ at the top of SoundexTest.cpp to make it compile. I’m using macport’s gcc47. Xcode DP6 is installed with command line tools.

Without I got:
/Users/claus/devel/tdd/SoundexTest.cpp:5:2: error: ‘string’ in namespace ‘std’ does not name a type
/Users/claus/devel/tdd/SoundexTest.cpp: In member function ‘virtual void SoundexEncoding_RetainSoeLetterOfOneLetterWord_Test::TestBody()’:
/Users/claus/devel/tdd/SoundexTest.cpp:15:25: error: ‘class Soundex’ has no member named ‘encode’
/Users/claus/devel/tdd/SoundexTest.cpp:15:35: error: unable to deduce ‘auto’ from ‘’
/Users/claus/devel/tdd/SoundexTest.cpp:15:7: warning: unused variable ‘encoded’ [-Wunused-variable]

Maby something specific to my setup?

Regards
Claus

patch instructions for the OS X install are missing a “-i” flag, i.e line should read:
patch -p1 -i [path to file]/rlog.diff

I copied the text in the comment to a file and saved it locally. Also I had to install autoreconf using “sudo port install automake autoconf libtool”. Finally had to run “automake —add-missing” prior to running autoreconf

“hapharzardly” -> should be “haphazardly”

The code examples at pragprog.com/titles/lotdd/source_code for chapter 5 no longer work with Google Mock 1.7 :-(
You get compiler errors about ambiguous IsEmptyMatcher in c5/1/AddressExtractorTest.cpp.
The root cause is a new matcher in gmock 1.7 with the same name (defined in file gmock-more-matchers.h)! It’s defined in namespace testing but since we open up the testing namespace in the book code the compiler now has two matcher to choose from.
A couple of solutions proposals.
1) Wait with opening the testing namespace until after last use of the IsEmpty-matcher. Thus,
class AnAddressExtractor: public Test {
becomes
class AnAddressExtractor: public testing::Test {
and add using namespace testing; ReturnsAnEmptyAddressWhenNoAddressFound.

2) Add a namespace around at least the definition of the matcher and its use. Anonymous namespace will do.

3) Rename the matcher from IsEmpty to something else not already defined within the namespace testing from Gmock.

In the middle of the first paragraph you write:

“… (first inserting an empty vector if needed).”

It’s not needed. The code

auto it = purchaseRecords_.find(symbol);
if (it == purchaseRecords_.end())
purchaseRecords_[symbol] = vector();
purchaseRecords_[symbol].push_back(PurchaseRecord(shareChange, date));

could just has well been written:

purchaseRecords_[symbol].push_back(PurchaseRecord(shareChange, date));

since operator[] adds an empty record if it doesn’t already exist. No need to repeat the implicit search with operator[].

c6/17/Portfolio.h
Template interface should either be

T Find(const std::unordered_map<std::string, T>& map, const std::string& key) const

Or, the whole implementation could be
{
return map[key];
}
since the the container is copied with the original interface. operator[] does all the magic for unordered_map but doesn’t work on a consted unordered_map.

End of second paragraph read (Look at the
source download to see the final tests.)

Looking at the source code downloaded from the book site there is a empty directory c6/20. Is that where the reference goes? In that case the code is missing :-)

In “4. We copy the for loop …” the code shows

rLog(channel, “writing %i samples”, samplesToWrite);

but should be

rLog(channel, “writing %u samples”, samplesToWrite);

as the code read in version 3. And it’s pretty obvious now since the declaration of samplesToWrite is just two lines above, uint32_t.

Consider using nullptr instead of 0 as the return value for
RLogChannel *getComponent(RLogChannel *componentParent,
const char *component){ return 0; }
}

It’s more modern C :-)

On Ubuntu 13.10 I had the following linking errors regarding pthread in the chapter 2 exercises:

undefined reference to `pthread_getspecific’

In order to fix this, I had to change the order of the CMakeLists.txt file from:

target_link_libraries(test pthread)
target_link_libraries(test gmock)
target_link_libraries(test gtest)

to:

target_link_libraries(test gmock)
target_link_libraries(test gtest)
target_link_libraries(test pthread)

The bad example code and the improved" version at the bottom of the page are exactly the same.

1st paragraph, last sentence:
but others wom’t -> but others won’t

Except for the increased indentation is HoldingServiceTest.cpp identical in Branches 18 and 19.

The execution statement is isolated in Branch 20.

Maverick (OS X 10.9) changed the default stdlib library.
To get Ch.2 examples working, I had to force gmock to build with libc.
Use:
./configure CXX=“clang -std=c+11 -stdlib=libc+” && make

I also needed to add a couple of symbolic links:
cd $GMOCK_HOME
ln –s lib/.libs mybuild
cd gtest
ln –s lib/.libs mybuild

and add this env variable to ~/.bash_profile:
export DYLD_FALLBACK_LIBRARY_PATH=$GMOCK_HOME/lib/.libs:$GMOCK_HOME/gtest/lib/.libs:$DYLD_FALLBACK_LIBRARY_PATH

For jsoncpp in Ch.5, I had to edit the SConstruct file:
elif platform.startswith(‘linux-gcc’):
env.Tool( ‘default’ )
env[‘CXX’] = ‘clang -stdlib=libc’ #scons does not pick-up the correct one !

and add a symbolic link:
$ cd $JSONCPP_HOME/libs
$ ln -s linux-gcc-4.2.1/libjson_linux-gcc-4.2.1_libmt.a libjson_linux-gcc.a

Download the appropriate file and unpack, perhaps into a new directory named pputest within your home directory.
pputest should be cpputest.

If I understand the example correctly httpServer() should be replaced with httpService() in the following section:
“With respect to our example, the difference is that the httpServer() function is a simple getter that returns a member variable referencing an existing instance, whereas in Override Factory, httpServer() is responsible for constructing the instance.”

You wrote:

“To compile, we added an empty declaration for the Soundex class.”

It should be:
“To compile, we added an empty definition for the Soundex class”

1. The Soundex class / algorithm mentions the case of unrecognised characters, and tests for them with the IgnoresNonAlphabetics test. However, it does not mention or demonstrate whether we should treat encodings on either side as separate (i.e. the same as separated by a vowel) or not. Another test DoesNotCombineEncodingsSeparatedByUnrecognisedCharacters or DoesCombineEncodingsSeparatedByUnrecognisedCharacters would be a good idea.

2. The Soundex encodings map should probably contain characters instead of std::strings. Doing this from the start makes it more interesting from the point of view of handling invalid characters, as well as indicating another reason for the NotADigit constant (i.e. std::optional doesn’t exist yet), vs using an empty string as NotADigit.

There is no difference between the code samples trying to show the Arrange, Act, Assert, and the code that makes it obvious about the different sections. Did the white space get removed in Kindle sample?

In the Kindle version of the book on page 85/334. I don’t think it’s correct, but I’m not sure what I should be seeing as described in the text between the code blocks

The mnemonic Arrange, Act, Assert (AAA, usually spoken as triple-A), devised by Bill Wake,[ 10] reminds you to visually organize your tests for rapid recognition. Looking at this next test, can you quickly discern which lines of the test relate to setting up a context, which line represents execution of the behavior we want to verify, and which lines relate to the actual assertion?

c3/ 14/ RetweetCollectionTest.cpp TEST_F( ARetweetCollection, IgnoresDuplicateTweetAdded) {     Tweet tweet(" msg“, ”@ user");     Tweet duplicate( tweet);     collection.add( tweet);     collection.add( duplicate);     ASSERT_THAT( collection.size(), Eq( 1u)); }                       
With the lines clumped together, it takes a few extra moments to see exactly what’s being tested. Contrast that version of the test with code that makes the Arrange, Act, and Assert portions of the test obvious.

c3/ 13/ RetweetCollectionTest.cpp TEST_F( ARetweetCollection, IgnoresDuplicateTweetAdded) {     Tweet tweet(" msg“, ”@ user");     Tweet duplicate( tweet);     collection.add( tweet);     collection.add( duplicate);     ASSERT_THAT( collection.size(), Eq( 1u)); } 

Langr, Jeff (2013-10-10). Modern C Programming with Test-Driven Development: Code Better, Sleep Better (p. 85). Pragmatic Bookshelf. Kindle Edition.

Minor issue if you follow along from the first c5/1 code as a starting point. The test will pass verify on page 109 kindle.

c5/1 code does not fail the verify() assertion for PlaceDescriptionTest(), since it already implements the logic for creating a URL that ends with the lat/lon.

c5/2 and c5/3 do fail summaryDescription, since they both pass in “” URLs

Page 192/334 links to the wrong code sample.

1. There is no change in the whitespace for the “Misleading Organization” unit test X.
2. It should link to c7/20/libraryTest/HoldingServiceTest.cpp, not c7/19/libraryTest/HoldingServiceTest.cpp
3. The text should clarify that this is a white space change, which groups the test code into 3 sections (AAA).

Last function in link:
media.pragprog.com/titles/lotdd/code/c7/18/libraryTest/HoldingServiceTest.cpp

TEST_F(HoldingServiceTest, X)
{
HoldingBarcode barcode(THE_TRIAL_CLASSIFICATION, 1);
string patronCardNumber(“p5”);
CheckOut(barcode, branch1, patronCardNumber);
date_duration oneDayLate(Book::BOOK_CHECKOUT_PERIOD + 1);
holdingService.CheckIn(barcode.AsString(),
*arbitraryDate + oneDayLate, branch2->Id());
ASSERT_THAT(FindPatronWithId(patronCardNumber).FineBalance(),
Eq(Book::BOOK_DAILY_FINE));
}

media.pragprog.com/titles/lotdd/code/c7/20/libraryTest/HoldingServiceTest.cpp

TEST_F(HoldingServiceTest, X)
{
HoldingBarcode barcode(THE_TRIAL_CLASSIFICATION, 1);
string patronCardNumber(“p5”);
CheckOut(barcode, branch1, patronCardNumber);
date_duration oneDayLate(Book::BOOK_CHECKOUT_PERIOD + 1);
// Add newline

holdingService.CheckIn(barcode.AsString(),
*arbitraryDate + oneDayLate, branch2->Id());
// Add newline

ASSERT_THAT(FindPatronWithId(patronCardNumber).FineBalance(),
Eq(Book::BOOK_DAILY_FINE));
}

By adding spaces between the setup, method in test, and assertion allows someone to quickly scan for the relevant information.

“On failure, the lines between [RUN] and [OK] might help us understand our failure.”
-> “the lines between [RUN] and [FAILED]”

“On failure, the lines
between [ RUN ] and [ OK ] might help us understand our failure. ”

[ OK ] should be replaced with [FAILED]

The last line of page 28 “If we forget to use TEST_F, any test code attempting to use fixture member errors will fail compilation.” has typo.

Code for chapter 8 and 9 does not compile under Ubuntu 19.04.

:true_type)’:
/usr/include/c/8/bits/std_function.h:164:11: error: ‘__dest’ does not name a type
::new (__dest._M_access()) Functor(_source._M_access<_Functor>());

At the end of the 2nd paragraph: … new directory named pputest within your home directory.

‚pputest‘ should be ‚cpputest‘.

In the helper method ASSERT_EQUAL_WITH_LENGTH the paramter ‚length‘ is checked against strlen(actual) which comes from ‚len‘. Checking length against strlen(expected) would fail if the function GetNextLine returns an unexpected value for len.