Historical errata for Test-Driven Development for Embedded C

Unnecessary comma: “…on a team creating, an
embedded…” should be “on a team creating an
embedded”.

In sidebar, missing “a”: “But there are few capabilities…” should be “But there are a few capabilities…”.

The subscript on page 12 is not showing in the iPhone (.mobi?) version.

I am using Stanza 2.1.1 and it all just reads as “( T)”. It’s fine in the PDF version.

“… behavior of the the code in a test.” should be “… behavior of the code in a test.”

In the sample code, the call to “checkExpected” shouldn’t be commented out.

“LedDriver_TurnAllOff( ) is not masking the bits” should read “LedDriver_TurnOff( ) is not masking the bits”

“You could refactor the tests so that more of the tests depend on the query functions.”

It’s worth pointing out that just relying on the query functions stop you testing that the hardware address is still being set, which is the main point of the driver.

The reference to “Excerpt from: Taming the Embedded Tiger” looks messed up on iPhone version.

Just under the diagram at the top of the page, “unknownable unknowns” should be “unknowable unknowns”.

In the section “My Big AH-HAH!”, the phrase “working on a team creating, an embedded communications system” seems to have a comma where one isn’t needed.

“I have setup” should probably be “I have set up”

checkExpected() is commented out in teardown() for some reason

“Remember the script create the header, sourse and test file. ” should probably be “Remember the script creates the header, sourse and test files.”

“It’s simple. LedDriver_TurnAllOff( ) is not masking the bits that should not be affected.” should probably refer to LedDriver_TurnOff() instead of LedDriver_TurnAllOff().

different tenses: “This kludge works, but it was ugly.” should probably be “This kludge works, but it is ugly.”

Missing period at end of sentence “In the next few subsections we’ll look at some common unit test approaches that could be at least partially replaced by TDD” - also, not sure if all of the approaches are technically “unit tests”

Confused by the test call to ScheduleTurnOn() in “LightScheduler_ScheduleTurnOn(3, EVERYDAY, 1200);” as the block diagrams (e.g., Figure 8.4) only have three interface functions for LightScheduler: Add, Remove, and Wakeup. Something seems to be inconsistent. Also, consider changing the name of ScheduleTurnOn() (or Add() or whatever) to have a better name: light id, enum date, and time in integer minutes is not obvious from ScheduleTurnOn.

incomplete phrase “We develop right up the unknown”

TimeService_SetPeriodicAlarmInSeconds() and TimeService_CancelPeriodicAlarmInSeconds() show up here, kind of out of the blue; I don’t think they have been shown previously; should there be a test for them?

it might help readability if the same day/minute representation/naming of Time was used within ScheduledLightEvent; e.g. “timeminuteOfDay != lightEvent>minute” might become “timeminute != lightEvent>minute”;

DoesLightRespondToday2() appears here out of the blue; DoesLightRespondToday() appears on the next page (132); maybe the “2” is a refactored version?

Line 8 has “…cygwin isa…” where it should have “…cygwin is a…”

Line 10 has “…need a to…” where it should have “…need to…”

Line 2 has “an build” where it should have “a build”

Line 8 has “…big bucket to time…” where it should have “…big bucket of time…”

At the end of the paragraph “Manage Dependencies”, the text is “during initialized” and should be “during initialization”.

In point number 4, “sourse” should be spelled “source”.

Somewhere in the test runs starting at the top of page 59 (“OK (4 tests, 4 ran, 4 checks, 0 ignored, 0 filtered out)”) and 2/3 of the way down page 60 (“OK (6 tests, 6 ran, 7 checks, 0 ignored, 0 filtered out, 1 ms)”), an extra check was added. I’m getting 6 tests and 6 checks at the same point.

Second sentence, “treat this runtime errors” should be “treat this runtime error”.

The quote at the top of the page is attributed to Professor Wagstaff, while in the first paragraph it’s Professor Flagstaff.

“The most popular answer I have heard, from polling conference attendees, is 50%. That is a big bucket to time.”

Should that be, “…a big bucket OF time”?

The example for AllTests.cpp did not work for me. CppUTest has a file called AllTests.cpp that calls

CommandLineTestRunner::RunAllTests

instead of a RUN_ALL_TESTS macro. That does work for me.

“test files are in place and part of out automated build.”

out —> our

“There are magic numbers in the LedDriverTest.cpp file for the boundary values. They could be removed, but I’ll leave them for now.”

Not so: you had us remove them on page 70.

“Here is where your development system and Dual-Targetting come into play”

Targetting —> Targeting

In the section, “Eclipse IDE” the sentence “No need to start and editor war here, but I like the eclipse with CDT
(C/C Development Tools).” should probably read, “No need to start an editor war here, but I like Eclipse with CDT.”

“CppUTest has a build in” should probably be “CppUTest has a built-in”

just a style thing - when possible, I like to use calloc() instead of malloc for operations like:

buffer = (char *)calloc(buffer_size);
buffer_offset = 0;
buffer_used = 0;

instead of:

buffer = (char *)malloc(buffer_size);
buffer_offset = 0;
buffer_used = 0;
buffer[0] = ‘\\0’;

just seem to make the intent clearer (possibly at the expensive of some run-time overhead clearing the buffer).

“FormatOutputSpy_GetOupu” should be “FormatOutputSpy_GetOuput” in:

void setup() {
UT_PTR_SET(FormatOutput, FormatOutputSpy); FormatOutputSpy_Create(100); actualOutput = FormatOutputSpy_GetOuput(); buffer = CircularBuffer_Create(10);
}

“makes sure the code handles is design maximum”

is —> its

Is the spelling “Adaptor” correct, rather than “Adapter”? At best, it seems English instead of American.

2nd paragraph - evolved, designs we (should be “were”) not improved

Figure 3.1 is a UML class diagram

5.1 add bullet to list:

1. Cross Compilers for the target hardware are typically considerably more expensive than native compilers and the development team may have a limited number of licenses available.

“TDD generated unit tests often are more like gray-box tests”
Since most of the TDD tests are actually hand-coded, I would say that the use of the word “generated” is inconsistent would industry usage and elsewhere in this book - how about “created” or similar

the CMocked generated .c file of 255 lines - don’t want it listed in the book but in the PDF it be would nice to have the down-load link so we could look at the code

Spurious #endif at the bottom of page.
(Also the footer says B5.0 / June 01)

section 5.3
… “while the development system compiler has another set of bugs.” suggest “while the development system native compiler” for clarity and general terminology usage

With the refactored test code, I don’t see where the tests actually call any assertions (the call to checkExpected() in the teardown is commented out).

And a note on that: I find it surprising for the tests not to have their own assertions—not that they can’t call checkExpected themselves, but factoring that out to the teardown seems a little odd [not horrible to figure out with just 2 tests, but I think it’d be hard to figure out with multiple test groups, some of which factor out to teardown, some of which don’t, and multiple tests, some of which will have some assertions of their own].

The sentence reads: “Instead, we must passed the LED’s address to the driver during initialization. ” but probably should say “pass” instead of “passed”

The sidebar for Dependency Injection is at the top of the page. It seems like it would fit better at the end of the “Manage Dependencies” section since it’s really not a sidebar and instead directly in the flow

The State Machine on p50 may already be too complicated, but I was wondering if maybe you could color code the states with Red/Green/Refactor (maybe red shading to green for refactor? or maybe just green, or maybe blue or..)

Feathers quote reads “vise”, not “viCe” in the original.

I was thinking we were going to get something really racy when the sidebar heading was “Software Vice”, maybe something about how tawdry you feel after writing code that may or may not work because it’s not tested, or how addictive that green bar is, like another shot of heroin to a junkie.

When I mentioned the Gang of Four in the People’s Republic of China everyone got really tense so those are some No-Longer-Politically-Correct people.

Even disregarding that, it seems like the straight-forward authors names should be in the text, with maybe a footnote to the unfortunately named Gang Of Four…

The text reads " it can be 8:42—or even leap day“. Maybe it should be ”or even a leap day" (added an “a”); however, I think it might make more sense if it were a leap second given the context.

The text reads “supposed to happen at 8:42—you either get
one chance a day” —- but I couldn’t help but get distracted thinking that I’d have two chances per day. Maybe it should be 20:42 or 8:42AM (in both places in that paragraph).

The box for TimeService in the picture on this page and page 121 is smudged, not crisp like the other boxes.

Rather than the first test being “ScheduleOnTodayNotTimeYet”, why not do the creation test first? It seems to work out that way quite often anyway.

The code for Light_Scheduler_Wakeup() seems to unnecessarily introduce
ScheduledLightEvetn * lightEvent = &scheduledEvent;

This is not called for given the code in the method, so I’m suggesting it be taken out. If there is a reason for it, I’m really curious to know what it is!

[FWIW, I think the reason is that the code is reverse-engineered om the refactored solution that has checkEvent() function. Even so, unless you’re really suggesting proactively introducing pointers for arguments to functions you might want to extract later, it seems like lightEvent doesn’t belong here]

I would definitely want to test DoesLightRespondToday in isolation for two reasons:
- tests focused on just this method will be easier to create, requiring less superstructure (or in turn driving this complex logical method to have lower coupling), and easier to list
- I’ve found testing complex logic through layers of intermediary calls obfuscates the problems when they’re there. Are they in the intermediaries? In the logic? Who knows…

So my suggestion is, rather than testing as you did to follow up below (ScheduleWeekEndItsFriday, etc.), to instead hammer DoesLightRespondToday with tests, and then have perhaps only a Wakeup tests for yes, no, and error. The tests will then more closely match the code they’re testing (after all, Wakeup does not have that complex logic).

The question of how to control visibility is coming up, I hope…

While I’m not morally opposed to assertions in the setup or teardown, I think it’d be better if there were also a specific test for them since figuring out what the heck went wrong is often pretty difficult with the assertion outside the test.

In this case, if the destroy fails to cleanup the callback, every single test will fail, which will mean quite a bit of noise to work through to find the golden nugget of truth.

Instead, how about have a DestroyRemovesCallback test?

And while you’re at it… it would probably also useful to decide and test what happens when you Destroy a Destroyed Schedule.

It’d be a shame if the code in ScheduleTwoEventsAtTheSameTime didn’t use the previously defined whenItBecomes() function…

Shouldn’t the code snippet for LightScheduler_Create show
static ScheduledLightEvent scheduledEvents[MAX_EVENTS];
as well? Or am I missing something?

In the RejectsTooManyEvents, 128 comes out of nowhere. Shouldn’t that come from a query to the LightScheduler, or instead just be in a do{} while{} that stops only when your patience runs out (say 100000 iters) or when there’s a Fail_TooManyEvents returned?

I realize that you’re not creating a random number source suitable for gaming, however:

- I think that you have to run the RandomMinute_Get 300 times (on page 145) shows that the number of iterations used on page 144, only 100, is insufficient.

It’s important that tests be repeatable, and in order to do that, the test for “all in range” needs to be bumped up considerably (100x or so, which will still be fast)—especially if you’re making no consideration for an even distribution—to give good confidence that there’s not some less-likely random number lurking out there (e.g., if the translation function from [0, 1) -> [–30, 30] improperly handles the outer limits, a fairly common mistake)

Not on the page, but in the source code off the web,
t1/mocks/FakeRandomMinute.h

one of the functions spells “Fake” as “Fack”

Description calls for sprintf test case to test for null, but example shows the string “Hey”. B4 tested for a null string.

Visual Studio
“up-to-date version does not support a command line build.”
I haven’t tried the free VS 2010 version yet but you can compile from the command line on older free versions and just use a free GNU make for WIN32 to do your builds. It works for me. MS does make a good compiler these days.

The code that is supposed to inject a failure won’t do so.
Error is in the source code tarball.

Ambiguous / unclear sentence: “Implicit in development is what used to work, continues to work in the next release.”

Suggest change to ‘Implicit in using TDD with automated tests, is that during further development we can be sure that what used to work continues to work in the next release.’

Suggest need to add something about Lean to explain the phrase ‘institutionalizes waste’ in “TDD is defect prevention. DLP institutionalizes waste.” (footnote, with URL)

Ambiguous / unclear sentence: “A weakness in these tests are that they do not check that sprintf( ) is
respecting the end of the output buffer, writing characters after the string terminator”

Suggest change to ‘* i.e. that sprintf is not writing* additional characters after the
string terminator’

Ambiguous / unclear sentence: “A weakness in these tests are that they do not check that sprintf( ) is
respecting the end of the output buffer, writing characters after the
string terminator. These tests watch for buffer overruns by filling the
buffer with a known value and checking that the character after the
terminating null is not changed.”

Suggest change to ’ …string terminator. *[new paragraph] The following tests*…’

(this probably duplicates #44681)

Code is unmodified (3,“hey”) but test fails expecting 2 and getting 1! Code should be changed.

Top of the page: “He is…” => “Here is…”

“Two-stage structInitialization”

Seems to be an ‘are’ missing from: “expect( ) and given( ) are free form helper functions that are accessible
to all TEST( ) cases in the TEST_GROUP.”

The paragraph “You might think that Unity and CppUTest … but
conceptually identical.” might make more sense as the final para in section 2.3 where CppUTest is introduced.

(and reword “You may notice that …”)

“When this patterns is broken” - pattern

Perhaps clearer to add ‘so far’ into “What you have not seen so far is Test Driven Development.”

AmerEnglish: “are a couple mechanism” - ‘couple of’

AmerEnglish: “a couple modularity options” - ‘couple of’

“We used the some of the capabilities of C” - too many ’the’s

The last paragraph on the page reads incorrectly.

The duplicate switch statement code smell is exactly the problem that
the to the Open Closed Principle is designed to address

First paragraph
Recall the in the old design that each switch
should read
Recall that in the old design that each switch

Title Global Free-for-ll should read Global Free-for-all

Example referenced should pass, not fail, right?

(or maybe a typo)
In the code zip file, the README.txt (in the top folder) refers to a ‘BookCode’ folder, but the folder is just named ‘code’

The next test will force the driver to use the pass in ledAddress. -> ‘passed-in’

Watching the test case fail, shows that the test can detect a wrong result. -> Comma is not needed.

“cut in one use of the new code” / “compiling before cutting to it” -> confusing usage of “cut” directly after talking about cutting / copying / pasting. I would suggest something like using “replace one instance of the old code with the new code” and “compiling before switching to it”.

Building the code, all the test run. -> tests

“test come pretty quickly” -> tests

“Can it can detect a specific failure?” -> do the can-can, or maybe remove one…

“FakeLightController_getLastState( ) returns a a 0, 1, or UNKNOWN_STATE” -> too many “a”

Why not just expose scheduleEvent( ) and eliminate LightSched- uler_ScheduleTurnOn( ). -> should end with question mark

we’ll use a the ST Micro-Electronics -> no the needed

In addition -> should be followed by a comma. This occurs in a few spots (pg 186, 145)

The LedDriver, LightScheduler, RandomMinute, CircularBuffer, FormatOutput and FlashDriver demonstrate design -> should have what these are, something like “the X, Y, Z objects demonstrate”

Those condition check -> checks

Isn’t better to wait? -> Isn’t it better

A nice side effect of the application driving the interface, it is less likely that -> would suggest a rewording. Something like: A nice side effect of the application driving the interface is that hardware implementation details are less likely to pollute the application’s core

phone call with you cell phone -> your

You can find many answers that question -> to that question

You ask what is this conditional for? -> suggest quotes: You ask, “what is this conditional for?”

how out of control this con get, -> can

Like many code problems, Long Parameter List tend to happen -> tends

Will-Nilly -> Willy-Nilly. This is repeated a few times, even in the glossary

The code show no real distinction -> shows

As we refactor I’ll introduce -> add comma after refactor

It’s more common add the comments -> common to add

I’ll introduce a some helpful -> no need for the a

Dereferencing the event for day and minute will get lower the abstraction level. -> Not sure what the intent is here. Maybe trying to say “will lower the”?

We introduced pointer -> We introduced a pointer

the Time functions are are caught directly -> redundant are

Technical Dept -> Debt

When you are modifying Legacy Code (as Michael calls code without tests) -> You’ve already defined legacy in this way, keep it DRY :-)

Code that has dependency -> Code that has a dependency

can be quiet involved -> quite

MockIO intercept calls to IO_Read( ) and IO_Write( ) -> intercepts

role of tests in and environment -> an

explicitly included as inputs to linker -> explicitly included as inputs to the linker

Missing . on footnote 1

This should be in the blurbissimo: “You don’t need a
test for every day of every year, you just need a test for every day that
matters. This book is about writing those tests[…].”

“As the production code grows, so does a valuable suite of unit
tests, an asset as valuable as the production code itself.” Lose the first ‘valuable’?

there are spaces after the ( and before the T of each of the constants in the text.

“Just as with any skill, such as playing pool or skiing black diamonds,TDD skills take time to develop.” Should that be singular skill in the last clause?

“code rot” hyphenate?

“nonembedded code too” needs a comma before “too”. There are other cases of this, too, so search for it.

For the bullets, I’d use identical opening words, either all ‘A’ or all nothing. Additionally, the fact that the second word of a key phrase is italicized but not capitalized seems odd.

“good for first example” at bottom para is missing the word “a”

para between code snippets. “These tests” in sentence 1 and “these tests” in sentence 2 seem like we’re talking about the same tests.

I can’t help but want the tests to include a literal before the markup as well as after, i.e. “X%sX”

in “to read, understand and evolve,”, second from bottom para, the final serial comma is, say some, missing. Probably just tell me “delivered as designed”. I won’t bring it up again. :)

“you will seen another solution” at top para.

“You can find a more on Unity”

“You, of course can use whichever test harness you prefer.” interjected “of course” wants trailing comma?

“expected <2 0x2>
but was <1 0x1>” shouldn’t that be “was <3..”?

“make sure that pattern” reads like “be sure that the concept of pattern”, instead of “be sure that the four-stage pattern”

First para of prev page: “lead you through some of first steps”

3rd para of previous page: “But C is not an OO language, but”, the too “buts” seem awkward.

Last para prev page: “module is self-contained part of a system” -> “…is a self-contained…”

Liskov quote in 2nd para has double opening quotes.

static void given(int charsWritten)
{
\tTEST_ASSERT_EQUAL(strlen(expected), charsWritten);
\tTEST_ASSERT_EQUAL_STRING(expected, buffer);
\tTEST_ASSERT_BYTES_EQUAL(0xaa, buffer[strlen(expected) + 1]); —- ? SHOULD BE? —-> TEST_ASSERT_BYTES_EQUAL(0xaa, buffer[strlen(expected) + 2]);
}

void given(int charsWritten)
{
\tlength = charsWritten;
\tLONGS_EQUAL(strlen(expected), length);
\tSTRCMP_EQUAL(expected, buffer);
\tBYTES_EQUAL(0xaa, buffer[strlen(expected) + 1]); —- ? SHOULD BE? —-> BYTES_EQUAL(0xaa, buffer[strlen(expected) + 2]);
}

2nd paragraph, first line says:

“If the respect if low enough,”

It should be:
“If the respect is low enough,”

2nd paragraph, 2nd sentence: remove the word “to” from:
“Let’s give the driver 5 milliseconds to before
ending in an error.”

test-driven-development-for-embedded-c_b9_0.pdf,
page 44
“To keep your tests clear, make the pattern visible in you tests.” Second to last word should be “your”.

warrantee -> warranty
(englishplus.com/grammar/00000267.htm)

“take an honest look at you current process” -> your

“TDD’s crooked path has less risk
as the code is alway passing…” -> always

Missing plural in final paragraph on page: “Structural changes, while hunting down a failing test, can make it very difficult to get back to all test passing.” should be> “Structural changes, while hunting down a failing test, can make it very difficult to get back to all tests passing.”

Missing plural in first sentence of last paragraph: “Why do these small step?” should be> “Why do these small steps?”

Missing hyphen, first sentence of section 4.1, should be: “The simple-minded implementation from…”

Missing hyphen, second sentence of the first paragraph, should read: “If you want to have well-written tests,”

4th paragraph: Replace the ? with . in the sentence “Let’s find the problem?”

Last paragraph, add the hyphen: “It’s easier to see the ideas in the code when you extract them and wrap them in an intention-revealing name.”

2nd sentence on page, add the ‘a’: “…like the stones in a mountain stream.”

In the paragraph under the “Test Boundary Conditions” heading, change “no” to “not”: “In that case the design would no call for boundary checking.”

In the paragraph under the “Test Boundary Conditions” heading, “out of bounds” is not hyphenated, while on the next page it is repeatedly hyphenated when used in the same manner.

Remove the second comma in the next to last sentence on the page: “For instance, an out-of-bounds for an array on the stack, can corrupt the stack.”

Apostrophe abuse in the sentence just above the second download link: “It let’s the test check that…”

The run in the middle of the page shows the following:

………..!.
———————————-
13 Tests 0 Failures 0 Ignored

1. If there’s a bang mark among the periods, doesn’t that mean a test was ignored and, therefore, there should be 1 Ignored?
2. Given that TEST (LedDriver, IsOn) does both a TEST_ASSERT_FALSE and a TEST_ASSERT_TRUE, doesn’t that mean that if you hard code TRUE or FALSE as the return value, as it looks like you have above the run, you’re going to get a failure on one of them? Am I missing something?

“2. Run just the makefile from the code/unity directory.” - in B9 version of code zip, there is no makefile in that directory

“You can find the needed test files in code/unity/stdio.” - in B9 version of code zip, SprintfTest.cpp is under \\code\\tests\\stdio\\

“…might find you whole system being initialized in the test case” -> your

“The test doubles can monitoring data intended for”

“…intended for the DOC and and provide” - one ‘and’

“Now that the test fixture are assembled” -> fixtures

“and are ready to something
different” -> to do

I’m using the ePub version so the page number won’t be accurate if I give it, but the error is a double “the”:

“as you design the the interface”

I assume that’s all you need to find it.

I’m using the ePub version so the page number won’t be accurate if I give it, but the error is a double “the”:

In “Taking a Step Back before Claiming Done”:

“There are magic numbers in the LedDriverTest.cpp file”

This should be .c since we are still using Unity tests at this point.

I might go further in the diagram. The first point I make is that YourClass is much easier to test without all the non-dependent crap around. The second point is that even if we remove all the non-dependent classes, we still may well have a bunch of collaborators in the scene, and some of them may be awkward. That’s your second image. The third is that we still may want to microtest without those remaining dependents that are awkward. And a third image accordingly.

The test doubles are… This is not nearly strong enough, including the previous remark about not simulators. I find this needs to be shouted at geeks, so they grasp it. (My continuing campaign to call them microtests is precisely because of the difficulties people have with this concept.)

“TEST_ASSERT_EQUAL(4, sprintf(buffer, ”hey“));” should be 3 not 4 (as on page 34)

“A weakness in these tests are…” - is

“TEST_ASSERT_FALSE(expected, actual) - Checks any boolean condition” - so the parameter should be ‘(boolean condition)’

“The LedDriver is not * complicated example” - add ‘a’

“A case can be made for not adding the
previous test as at all” - remove ‘as’

Move last sentence in D3 “You can find the complete list of Unity assertion macros in unity.h.” as a parenthesis to the first sentence “Here is a short list of [some of] the TEST checks supported by Unity. (You can find the complete list of Unity assertion macros in unity.h)”

“If your target is this contained in I/O” - do you mean ‘constrained’?

“If your target is this contained in I/O” - do you mean ‘constrained’?

Too many ‘environments’ and ‘putchars’ in:
“The only I/O that CppUTest does is to output characters. It uses putchar( ).
If your environment is GCC compatible, there should be nothing to do
but have a putchar( ).
As long as you have a putchar( ) function, CppUTest should be ready to
run in your environment.”

at IL, we teach that the name for collaborators you want to double is “awkward collaborators”. it turns out that there are a lot of ways to be awkward.

“does not setup the next step” should be “does not set up the next step.”

“Setup” is a noun.
“Set up” is the verb form.

In the Runtime Error discussion, the stub .c and .h files do not match the downloaded code. Driver usage is not shown. You do show the test case, so I can figure it out from there.

The opening sentences of 9.3, Surgically Inserted Spy, are nonsense as if a copy/paste corrupted:

9.3 Surgically Inserted Spy
We have a utility module, the CircularPuffer. A CircularBuffer From time
to time, we need to When a system has printed output, it is usually
manually inspected.

…I do rather enjoy the image of a circular puffer, but you probably intended the P to be a B!

It also makes it hard to see what code is
really compiled under various situations.

Stephne should be Stephen

We’ll conclude with a few guidelines >> on on << writing and maintaining tests

.The we go test by test developing our first module. Maybe the correct sentence is “Then we go test…”

In figure 7.5, box labeled “Depended On Component”.

Should that be “Dependent On Component”?

Same as #42601 in ePub on Sony Reader (pages 41 and 42 in this edition).

One on too much in:
“We’ll conclude with a few
guidelines on on writing and maintaining tests.”

Missing “n” in:
“The we go test by test developing our first module.”

Re “There are no Visual Studio
Solution, Project or Workspace files in the code base. CppUTest comes
with VC++V6 .dsw and .dsp files.” - this is no longer correct, as the ‘B10’ code has Visual Studio 2008 files (and perhaps 2010 project files might also be included by 1st printing? ;-)

“Ububtu” -> Ubuntu

Strange effect with () and [].
In the PDF “&buffer[1] … buffer[0]” appears to the eye as () brackets within the paragraph text, but when cut & pasted is correct [].
Probably occurs elsewhere too.

Copyright banners are being pulled in as part of some code modules imported into the book. This looks untidy and is distracting / noisy.
(Although this currently only applies to two instances).

Perhaps you could have a word with the gerbils ;-)

The zip file’s URL disappears off the right margin in PDF (though the hyperlink works OK)

Two full stops at “Dependency Injection..”

Spurious ‘of’ in “And finally, do the simplest thing possible of to get this…”

2 x ‘the’ in “that the the test”

“..couple more helper function,” needs to be “…functions”

“in in the sidebar”

Remove ‘the’ from “described the like this:”

No need for ‘of’ in “some of common questions”

“FLSE” -> “FALSE”

‘had’ should be ‘hard’ in “It also makes it had to see”

Page relates a story, but lacks the usual story attribution and formatting

“tests scripts” should be “test scripts”

Bit late to comment that ‘challenge’ is used 4 times in 4 lines!

“Using Test-Driven Development for embedded software has its challenges.
Some of those challenges will be unique to your development
efforts. In spite of the challenges, putting TDD to work in the challenging
embedded environment is worth the effort.”

Should it be ‘they’ instead of ‘then’ in
“then simulate specific interaction
scenarios.”

Should LightScheduler_Wakeup() really be part of setTimeTo()?

reactionDay has appeared from nowhere in processEventDueNow() - not in parameter list.
Also (reactionDay == EVERYDAY) should continue, not return.
Both issues occur in two places.

‘today’ has also appeared from nowhere in processEventDueNow().
Also (reactionDay == today) should continue, not return.

Unless I’m missing something, we seem to be jumping ahead here without failing tests ;-)

Adding a test that uses TUESDAY seems to be at odds with adding code that checks for EVERYDAY?

[sorry to bang the drum, especially if CE has fixed these]

We should be seeing incremental changes to processEventDueNow() to add handling for WEEKEND / SATURDAY / SUNDAY, but this is missing from the PDF

MONDAY and EVERYDAY appear a few times before ‘enum Day’ is defined. Even allowing for the principle of failing-test-before-code, this seems wrong.

“We fast-forwarded through the day matching conditional logic” - now you tell me!
Perhaps this comment would be helpful around p.169/170

LIGHT_ enums appear (several times) before they are defined on p.176

Should FakeLightController.h appear here to explain FakeLightController_GetLastId() etc?

‘LightScheuler’ has lost it’s D

LS_ enums appear before their definition

“are a helpful” ..something, or remove the ‘a’

“the the code”

“Ramdomize” appears in a few places in the code

The first sentence in the third paragraph reads:

“The early phases of a TDD project are mundane to the point of seeming pointlessness.”

I believe you want to substitute ‘pointless’ for ‘pointlessness’ here. This is in version B11.0 (it’s not yet an option in the drop-down).

Version B11.0

You mention the “Red-Green-Refactor and Pavlov’s Programmer” sidebar in the first paragraph but say that it is “on the following page” when it’s really on the current page.

Version B11.0

In the first paragraph in section 1.5 I believe there is a problem with the tense in the sentence “Many developers have adopted it and would not go back to Debug-Later Programming.” Should this be ‘will not’ instead of ‘would not’?

Maybe it would be even more impactful to say that they can’t go back (I know I say that all the time), but that’s you’re call.

Version B11.0

Between pages 55 and 58 the test is named from LedsOffAfterInitialization to LedsAreOffAfterCreate. The unmentioned change might throw some people off.

Version B11.0

In the second paragraph you ask the user to note the type, however the type doesn’t show up in the code snippet in the book. Unless they’re looking at the downloaded code it’s not clear what the type of virtualLeds is.

Version B11.0

You mention a schematic in the third paragraph but I haven’t seen it anywhere.

Version B11.0

Suggest changing “Adding code before required by the tests adds complexity.” in the second paragraph to “Adding code before the tests require it adds complexity.”

Version B11.0

Unity’s TEST_FAIL macro doesn’t appear to take any arguments, I think you might want TEST_FAIL_MESSAGE instead.

The link for unity is broken. I think you meant:
unity.­sourceforge.­net not ‘.org’.

In 2.7 #1, it’d be helpful to have a link or cross-reference for where to download the book’s code. It’d also be helpful to have it near the beginning of the chapter. As far as I can tell it is only linked from page 22; it took me a fair bit of backtracking and searching around to find it.

‘when’ -> ‘went’ in “Our conversation
when like this:”

Code doesn’t compile. Missing a semicolon after TEST_GROUP, and TEST_FAIL should be TEST_FAIL_MESSAGE.

Patch:
@@ –314,10 +315,10 @@ TEST (LedDriver, OutOfBoundsLedsAreAlwaysOff)
/* END: OutOfBoundsLedsAreAlwaysOff1 */
#endif

-#if 0 /* START: StartingPoint */
+#if 1 /* START: StartingPoint */
#include “unity_fixture.h”

-TEST_GROUP(LedDriver)
+TEST_GROUP(LedDriver);

TEST_SETUP(LedDriver)
{

@@ –329,10 +330,11 @@ TEST_TEAR_DOWN(LedDriver)

TEST (LedDriver, LedsOffAfterInitialization)
{
- TEST_FAIL(“Start here”);
+ TEST_FAIL_MESSAGE(“Start here”);
}
/* END: StartingPoint */

The first exercise states to look for a README.txt in code/SandBox. There is no README.txt there or in that directory subtree.

The third line of section 2.2 says “at a couple example…” and should say “at a couple of example…”

On the first line of code:

TEST_GROUP(LedDriver)

this would not compile on my system until I put a semicolon after it:

TEST_GROUP(LedDriver);

I think the version of Unity that you’re using in your code is different than the one that can currently be downloaded from the Unity project.

In the sidebar, you use the word “vice” when you mean “vise.” This is also used on the previous page.

Middle paragraph on page 25: mentions a shared data item named “length” that does not appear elsewhere in the surrounding text or example code.

last sentence, first paragraph of Robert C. Martin’s foreword:
“probqably” should be “probably.”

On page 61, 6th line from the bottom:

TurnOnMutipleLeds should read “LedMemoryIsNotReadable”

In the “Fabric of Development” box there are two typos: extra space after comma in: “, by Jack Ganssle” and there should be a period after Ganssle.

Typoes in last line:
1. missing space between “theLightControllerSpy”
2. “FakeTimeSource” instead of “FakeTimeService”

In the snippet of code for the LightControllerSpy.c file where lastId and lastState are declared the #include “LightController.h” should probably be #include “LightControllerSpy.h”

Line 4:
“when you don’t kow all the details” should be
“when you don’t know all the details”.

Is it possible, that the unity version in jgade-code.tgz
doesn’t work under 64bit Linux?
I am working under ubuntu 11.04 and get compile and test-errors doing make in the code directory.
If you like i can supply a log.

greetings
Arne

Answer to brix AT gtnw.de

execution of make -f MakefileCppUTest.mk results in:
compiling FormatOutputSpy.c
cc1: warnings being treated as errors
mocks/FormatOutputSpy.c: In function ‘FormatOutputSpy’:
mocks/FormatOutputSpy.c:64: error: implicit declaration of function ‘vsnprintf’
make: * [objs/mocks/FormatOutputSpy.o] Error 1

Needed to modify MakefileCppUTest.mk, change

CPPUTEST_CFLAGS = -std=c89 to
CPPUTEST_CFLAGS = -std=c99
to successfully compile and run all CppUTest tests.

Using GCC 4.4.5 on Ubuntu 64bit 10.10

Below code for TEST_GROUP_RUNNER(sprintf), the sentence should read “Essentially, this TEST_GROUP_RUNNER() calls the …” instead of “Essentially, this RUN_GROUP_RUNNER() calls the …”.

For CppUTest test cases to be identical to unity test cases, as stated above the test case code, then the line on page 25, given((sprintf(output, “%s\
, ”Hello World“)); should be the same as the code in page 20, given((sprintf(output, ”Hello %s\
, “World”));

In the paragraph below the definition of the typedef, the sentence is “Inside the .c file for CircularBuffer, the struct elements can be defined.”
The word “elements” is used to refer to the components of a structure, but the more common term is “members”. Elements usually refer to components of an array.

Index entry for multiple-use modules should actually be part of the entry for multiple-instance modules which should include a reference to page 32.

Just below section “Don’t Let …”.
The sentence starts “The ledsAddress is not stored…”. At this point, ledsAddress has not been mentioned. Confusing to reference something not defined until page 44.

Near bottom of page, ledsAddress is mentioned again, but never defined in code. Was it supposed to be defined in LedDriver_Create on page 40?

Appendix Section C.3: TEST Condition Checks

In the bulleted list the entry “CHECK (boolean condition)” appears twice, first at the beginning of the list and second on page 325 in paper after “CHECK_FALSE(boolean condition)”

First code block on the page, in the parameters of TEST_ASSERT_EQUAL, change 0xffff to ALL_LEDS_ON

In the refactor to remove duplications section, the function header has
static void scheduleEvent(int id, Day day, int minuteOfDay, int event)
But in the function that follows, the variable day is not used. Given the surrounding text, I believe it should have a line which says
scheduledEvent.day = day;

In the paragraph before 11.7 Where Are We?, it says “Like I said before, its OK to think ahead; just try to act on the design vision only once the tests to pull it in.”

I think there is a word missing. Maybe, “… only once the tests exist to put it in”?

191 first code block: The line

IO_Read(address);
is missing before
return FLASH_SUCCESS;
The same is true in the first code block on page 192.
p.193 last code block:

FakeMicroTime(0, 500);
needs to be
FakeMicroTime(0,50);
in order to force 10 iterations, as the test case assumes below.

In section 2.6, the following text should say “your” rather than “you”.

“I invite you to put you new knowledge to work”

The line numbers (193 and 211) in the error “report” on top of page 98, is not corresponding to the “downloadable”
“Download unity/LedDriver/LedDriverTest.c” on page 97

“TEST (LedDriver, IsOn)
LedDriver/LedDriverTest.c:193: FAIL
Expected FALSE Was TRUE
.
TEST (LedDriver, OutOfBoundsLedsAreAlwaysOff)
LedDriver/LedDriverTest.c:211: FAIL
Expected TRUE Was FALSE ”

Dubious use of “an” in the phrase:
“That would indicate an the loop won’t end by itself.”

Should be:
return UnityMain(argc, argv, runAllTests);
instead of:
return UnityMain(ac, av, runAllTests);

Unity misspelled in:
By default, Unit uses putchar( )

Repetition of:
CHECK (boolean condition): Checks any boolean condition

At the last line but one - “Early in a embedded development project” should read “Early in an embedded development project.”

About the use of const in code fragments (two places at lines 10 and 16) - “int PlatformSpecificStrStr(const char * s, const char * other) const {…}” should read “int PlatformSpecificStrStr(const char * s, const char * other) {…}” - i.e., the 3rd use of const is misleading.

Under the section called “Preprocessor substitution” the function prototype name cpputest_ralloc() should be replaced with cpputest_realloc().

At the end of the third line and continuing onto the fourth line, “FakeTimeSource” should say “FakeTimeService”.

Also, at the start of the third paragraph, the call to TEST (LightScheduler, ScheduleOnTodayNotTimeYet) should read TEST (LightScheduler, ScheduleOnEverydayNotTimeYet) to match its implementation on page 134.

Fail message for “TEST (LedDriver, OutofBoundsLedsAreAlwaysOff)” should be “Expected FALSE Was TRUE” because “TEST_ASSERT_FALSE” is written in the test code for “OutofBoundsLedsAreAlwaysOff”.

need ;
TEST_GROUP(LedDriver);

This test:

TEST (LightController, AddingDriverDestroysPrevious )
{
LightDriver spy = LightDriverSpy_Create(1);
LightController_Add(1, spy);
LightController_Destroy();
}

doesn’t appear to check anything, which makes it a little unclear. I suppose the test library signals an error if there’s a memory leak, but a comment at the end of the test would probably help clarify that. I didn’t understand it the first few times I read the test.

Section 6.4, paragraph two reads “… and load tests should help determine whether the system can meets its design limit”.

-Either drop the ‘s’ on meets, or drop the word ‘can’.

Last sentence of section 6.8 reads “Simulating a sequence of interactions is much less complex than a simulation of the whole and very effective”.

-I believe you want this to read “… and (is) very effective”

You wrote “TimeService_Set-
PeriodicAlarmSeconds” at the body of the book but real name of the function is “TimeService_SetPeriodicAlarmInSeconds”.

In TEST_SETUP, you write to the space to which “expected” points. (One byte is written: the null terminator for the empty string.) However, no space has been allocated for it, and the pointer is not initialized; it’s just a (const) char pointer.

The same thing is also done on page 24.

Judging by the CppUTest output (on pp. 26-27), “checks” appears to refer to the number of checks that failed—not the number of condition checks made, as described on pg. 26.

Omitted #endif from include guards in D.3.
(That is, in include/LedDriver/LedDriver.h. I didn’t check if it’s this way in the code download.)

On the top line of the page, there should be a space between “a” and “printf()-like”.

Fix Unity IGNORE test. See prag topics topics/10126#30451

In the description of ‘Test spy’, there are three ‘CUT’s but second one should be ’DOC’.

“so the test can verify that the correct parameters have been passed to the CUT” —> “so the test can verify that the correct parameters have been passed to the DOC”

In the third line of the first paragraph of ‘Test the Wiring’,
LightScheduler_WakeUp() is wrong in case. Its name uses ‘up’ rather than ‘Up’.

In the third paragraph (not counting code sections).

“If you are using printf() directly, you can do the same thing, initializing FormatOutput_Impl() like this:”

==> “initializing FormatOutput() like this:” (without ’_Impl)

Two test outputs say the name of test is “TEST (Flash, ProgramSucceedsReadyImmediately)” but the name is “TEST (Flash, ProgramSucceedsReadyImmediately)” in the page 167 and the code.

In the middle, “The Flash_Write() call has the parameters reversed; we get this error:” —> “The IO_Write() call has the parameters reversed; we get this error:”

In the first code snippet, it is simply wrong because the .Destroy initializer missed the comma at the end of the line.
However, the referencing functions here should be file scope functions.

static LightDriverInterfaceStruct interface =
{
.Destroy = destroy,
.TurnOn = turnOn,
.TurnOff = turnOff
};

In the second code snippet, the ‘brightness’ function pointer is better named like ‘SetBrightness’ to be consistent with others (TurnOn, TurnOff, Destroy, even the generic function name ‘LightDriver_SetBrightness’)

void LightDriver_SetBrightness(LightDriver self, int level)
{
if(isValid(self) && self->SetBrightness)
self->SetBrightness(self, level);
}

From page 277, all instances of “LightScheduler_WakeUp” should be consistent with earlier part of the book. —> “LightScheduler_Wakeup” (‘u’ in lower case)

In the code snippet ‘isEventDueNow’, daysMatch() should take today and day as its parameters because it takes (Day, Day) here. ‘daysMatch(Time*, Day)’ version will be followed in the next section.

I found that BDD section(14.6) seems contain the wrong code snippet.

It the page 283 of pdf(2.0), BDD sections shows two code snippets,
1) TEST (LightScheduler, ScheduleWeekEndItsSaturday) before refactoring
2) TEST (LightScheduler, ScheduleOffWeekendAndItsSaturdayAndItsTime) after refactoring

However, the text below the second TEST() says “the refactored test is more declarative and …” but two tests are almost the same with the invariant values replaced by TEST_GROUP variables.
(of course, there are some minor differences such as test name, Wakeup/WakeUp, and On/Off…)

See..
1)
tests/HomeAutomation/LightSchedulerTest.cpp
TEST (LightScheduler, ScheduleWeekEndItsSaturday)
{
LightScheduler_ScheduleTurnOn(3, WEEKEND, 1200);
setTimeTo(SATURDAY, 1200);
LightScheduler_Wakeup();
checkLightState(3, LIGHT_ON);
}

2)
t1/tests/HomeAutomation/LightSchedulerTest.cpp
TEST (LightScheduler, ScheduleOffWeekendAndItsSaturdayAndItsTime)
{
LightScheduler_ScheduleTurnOff(lightNumber, WEEKEND, scheduledMinute);
setTimeTo(SATURDAY, scheduledMinute);
LightScheduler_WakeUp();
checkLightState(lightNumber, LIGHT_OFF);
}

For the text to be valid, the second code snippet should be in BDD style (given/when/then) and I found the code in that style (i guess you planned to use that code) in the t1/tests/HomeAutomation/LightSchedulerTest.cpp file.
(on the line 128)
TEST (LightScheduler, ScheduleOffWeekendAndItsSaturdayAtTheScheduledTime)
{
given(lightNumber); isScheduledFor(WEEKEND); toTurnOffAt(scheduledMinute);
setTimeTo(SATURDAY); at(scheduledMinute);
then(lightNumber); is(LIGHT_OFF);
}

BookCode/SandBox/unity/LedDriver/LedDriverTest.c:44

/* TEST_FAIL(“Start here”); */

TEST_FAIL macro does not exist for Unity. Should be TEST_FAIL_MESSAGE.

I think that one line is missing in section 8.5.
"You get a shot of testability with a portability chaser.

needed for the TimeService is kind of the opposite of the LightControllerSpy."

The start of the first sentence in the third paragraph of section 8.5 is missing.

In the code says: “FakeMicroTime_Init(0, 50);”
In the text at the begin of the next page: “First, we initialize FakeMicroTime to start at 0 and increment by 500 µs.”
The code is expected to wait for 5000us or 5ms, so the text is correct and the code has a typo.

In the second paragraph, ‘ThreadResume()’ should be ‘ResumeThread()’

“We discussed the need to isolating hardware dependencies”
Should be isolate

Middle of the page “It’ss”

“…cause for to celebrate!”
Should be cause to celebrate!

(wrong) It’ss done with another macro,
(correct) It’s done with another macro,

Sometimes it’s a cause for to celebrate!
should read
…celebration!

Data type of many parameters in sample are “int” like as below.

ex） LedDriver_TurnOn(int ledNumber)

I think you should “uint16_t” instead of int. It is the same reason as the author’s suggestion for “LedDrive_Create(uint16_t * address)” at page 55 of PDF.

The book says “This is a common pattern for
solving platform-independence problems.” But it seems “platform-dependence” to be correct since platform-independence is a good thing.

All helper function names for Led Driver start with a lower case except for IsLedOutOfBounds(). It should follow the naming rule and become isLedOutOfBounds().

In the book, the implementation for LedDriver_IsOn is as follows:

return ledsImage & (convertLedNumberToBit(ledNumber));

But it seems the following implementation is correct, since the return type of the function is BOOL:

return 0 != ledsImage & (convertLedNumberToBit(ledNumber));

LedAddress should be written in camel case: ledAddress.

“Does code like this change very often?”
By any chance, the original sentence was meant to be like follows: Is code change like this very often?

“If a DOC is difficult to set up and get into one or more desired states, it
may be best to substitute a test double.” should read “… substitute with a test double.”

“Identify collaborations that you expect to make automated tests difficult.” collaborations should be “collaborators” by any chance?

“Depended Upon Component” should be “Depended On Component.”

“Time is wrong, day is wrong” should be “Day is wrong, time is wrong” to match the order of words with other test case descriptions.

static void scheduleEvent(int id, Day day, int minuteOfDay, int event) function is missing a substitution for scheduledEvent.day: scheduledEvent.day = day;
The code is missing from the sample code as well.

Beginning of sentence lost in creation of 2nd printing.

“needed for the TimeService is kind of the opposite of the LightControllerSpy.”

should be

“The test stub needed for the TimeService is kind of the opposite of the LightControllerSpy.”

Test description should be ScheduleTwoEventsAtTheSameTime for TEST (LightScheduler, ScheduleTwoEventsAtTheSameTIme).

void LightScheduler_Create(void) has a loop variable ‘i’ but it is not required yet at this point.

The text and the code do not match. You say you set the loop counter 225 but it is 300 in the code. Which one is correct?

In the following sentence, did you happen to mean “complex day-matching conditional logic?” I thought so because the title of the paragraph is “Complex Conditional Logic.”

The next series of tests will help us drive the complete day-matching conditional logic one step at a time.

The term “RTC tic” is unfamiliar with me. Should it be “RTC tick?”

In page 181, the name for a test is WriteSuccessImmediately but the error message says WriteSucceedsReadyImmediately. Error massage seems correct.

It’s a minor but the text body says “Figure 23, Flash_Write sequence chart—success case, on page 167” but the title for the figure has () for Flash_Write.

Then the call to MockIO_Expect_ReadThenReturn(0, 1<<7); tells the mock to expect a read from location 0x0 and that the mock should return a 1 in bit position 7, signaling the device’s successful completion.

Is semicolon after (0, 1<<7) unnecessary?

you’ll see It’ss instead of It’s

Page:
——-
18 • Chapter 2. Test-Driving Tools and Conventions

Section:
————
Installing Unity Tests
It’s not evident from the example how test cases get run with the necessary
pre- and postprocessing. It’ss done with another macro, the TEST_GROUP_RUNNER().
The TEST_GROUP_RUNNER() can go in the file with the tests or a separate file. To
avoid scrolling through the file, I use a separate file.

The code snippets say “LightScheduler_WakeUp” but the text says “LightScheduler_Wakeup.” The codes are correct.

In TEST (Time, NotWeekendDays), CheckThatTimeDoesNotMatch(WEEKEND); is missing after givenThatItIs(FRIDAY);
The online code has the same problem, too.

Regarding email discussion with Dr. Newcomer, " and ’ matching is incorrect.

TEST (LightController, AddingDriverDestroysPrevious ), both text and code, have unnecessary space between Previous and ).

In the following sentences, the numbers do not match.

To mimic the concept of a partial abstraction in C and a
link-time test double, we need to split the source into two files. We’ll need these three files:

You say “As I mentioned earlier, it is critical to allocate a LightDriverStruct dynamically. You can see that we have by the struct dereferencing of base.” but you have not mentioned it anywhere.

In the sentence above LegacyFlashtest.cpp, MockIO_Expect_Read() should be MockIO_Expect_ReadThenReturn).

NUL should be NULL in the following sentence:

It makes sense that giving strtok() a pointer to a literal string causes a segmentation fault when strtok() starts inserting its NUL characters into read-only memory holding the literal string.

In the following sentence, principle should be principal:

We’ll start to pay down some of the principle on the technical debt and reduce the interest payments on future visits to this code.

The GroupName and TestName() pairs must be unique in the test build.
TestName() should be TestName.

In 14.2 Copy-Paste-Tweak-Repeat Antipattern, there are some cut-paste-tweak, which should be copy-paste-tweak.

In the 3rd paragraph, there is unnecessary “we”.

“These two operating systems are important because
we our product ships in two configurations, …”

The explanation for TEST_ASSERT_FLOAT_WITHIN macro is wrong. Compares two doubles should be compare two floats.

Test case ScheduleWeekEndItsMonday under the section Refactor the Tests cannot pass until the logic added in the Complex Conditional Logic section is added. The test case is added in the correct spot on PDF pg. 137, Paper Book pg. 150.

In Figure 11, one dotted line is missing - from Test to the second right TDOC.

The title for Figure 16 - The light scheduler should be LightScheduler.

Quotations for expectedOutput in the both tests are incorrect:

“Circular buffer content:\
”
“<31, 41, 59, 26, 53>\
”;

should be

"Circular buffer content:\

<31, 41, 59, 26, 53>\
";

In Flash memory program flowchart, the description for the while loop “i || d” should be “b7 == 1”. Paper book (1st print) does not have this problem.

In Flash memory program flowchart, the first action is to write x0 to offset address 0x40. However, the vendor’s manual says “Write 40h or 10h” to any address. Text and sample code do not agree with the vendor’s manual.

The following sentences are little bit misleading. You said “there is no failing test, as expected” first but later said “It fails.” No failing tests without adding a test case is just a false positive. How about modifying the sentence “If you build and run right now, there is no failing test, as expected.” to “If you build right now, there is no compilation errors, as expected.”?

I expect this test to compile; there were no interface changes. If you build and run right now, there is no failing test, as expected. Add the test into the TEST_GROUP_RUNNER(). It fails because we did the simplest thing that could possibly work at the end of the previous chapter, and it doesn’t work for this test.

In the first code snippet, findUnusedEvent function has unnecessary void for its parameter.

same to #50940

considerStartingANewTestGroup();
-> considerStartingANewTestGroup

exit(SUCCESS);
-> exit(SUCCESS)

void LightDriver_SetBrightness(LightDriver self, int level)
{
if(isValid(self) && self->brightness)
self->brightness(self, level);
}
=> should be =>
void LightDriver_SetBrightness(LightDriver self, int level)
{
if(isValid(self) && interface->brightness)
interface->brightness(self, level);
}

Thread_Destroy(Thread self) does not have a link to the online code.

Console output missing: “>> make” before compiling LedDriver.c

In the Unity test file sample a semicolon is missing after the declaration of the test group’s name. This leads to an error during compilation.
You wrote: “TEST_GROUP(GroupName)”
Should be: “TEST_GROUP(GroupName);”

MinGW and cygwin issues with the eclispe files. Here is the fix:

1) Deleted all the .project, .cproject, .cdtproject and .settings (this is a did) files to get rid of all the now obsolete files.
2) Open eclipse chose the directory above ‘code’ as the workspace.
3) The create a new project from File/New/Makefile Project from Existing Code/
\ta) browse to the ‘code’ dir
\tb) leave the toolchain as
\tc) say OK
4) Right click the project and tell it to build.
5) You might get some warnings
6) Repeat that process for t0, t1, t2, t3.

I did something in the structure of the project I don’t really care for. t0,1,2,3 are all contained in the same file tree as the ‘code’ project. It makes unnecessary rebuilds. It is better to turn off each project one at a time.

After you are done playing with the code under mingw or cygwin, I suggest getting a real development environment. Use a VM running some form of linux, or a straight linux machine. Any serious effort at TDD will be slowed by the turtle like sped of those emulation environments.

Picking a nit, but LED 3141 or LED 33 for that matter, induce Undefined Behavior. From the C Standard 6.5.7: “If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.”

Before the text “Now add the call to RUNTIME_ERROR(); the test passes.”, it says 11 Tests 1 Failures 0 Ignored.

However after the above quoted text, it says (after running make) 11 Tests 0 Failures 0 Ignored.

Should it not be 12 Tests 0 Failures 0 Ignored ?

The first paragraph after the bullet points says:
“The checks are also known as asserts or assertions. I’ll be using all three terms interchangeably.”. Should it not be “I’ll be using both terms interchangeably.” ?

At the end of the paragraph (on this page) with heading “The Test Safety Net”, the last sentence does not require ‘a’ - it should say "Here is the test for LightController_TurnOn() along with its TEST_GROUP:

The text in the brackets needs to be corrected to something like:
“remember that coding standard that said all functions must fit on one screen?”

Second sentence of “Installing Unity Tests” section:
“It’ss …” should be “It’s …”

In the .mobi (Kindle) edition there are several missing references that instead say “(as yet) unwritten content” in italics.

At bottom of page, ‘This lets you get very precise about which test cases are running’. Seem you forgot the noun following ‘very precise’. Completing this sentence will fill in the idea. lee.larson@smiths-medical.com

In the discussion about clocks roll over, since the timer has a microsecond tick period, a 32-bit counter register would roll over after a bit more than 71 minutes instead of 136 years while a 16-bit counter would roll over after a bit more than 65 ms instead of 18 hours.

probqably

Environment: Windows 10, Cygwin installed February 6th 2016 as described on page 312

jgade-code.zip downloaded
README.txt instructions followed
line 19 should read as “./configure” instead of “./configure.sh”
line 28: “make everything” fails to make t1, SandBox, MakefileUnity.mk.
The problem seems to be unity

make -i -C t1
fails with:
compiling common.c
In file included from src/util/common.c:29:0:
src/util/common.c: In Funktion »explodesInTestEnvironment«:
src/util/common.c:33:11: Fehler: Vergleich mit Zeichenkettenliteral führt zu unspezifiziertem Verhalten [-Werror=address]
assert(p == “Explode - intercepted call that cannot be made in test environment”);

make -i -C SandBox
fails with:
compiling unity_fixture_Test.c
In file included from ../unity.framework/src/unity.h:20:0,
from ../unity.framework/extras/fixture/src/unity_fixture.h:19,
from ../unity.framework/extras/fixture/test/unity_fixture_Test.c:16:
../unity.framework/extras/fixture/test/unity_fixture_Test.c: In Funktion »TEST_UnityFixture_PointerSetting_«:
../unity.framework/src/unity_internals.h:324:130: Fehler: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Werror=pointer-to-int-cast]

make -i -f MakefileUnity.mk
fails with:
compiling unity_fixture_Test.c
In file included from unity.framework/src/unity.h:20:0,
from unity.framework/extras/fixture/src/unity_fixture.h:19,
from unity.framework/extras/fixture/test/unity_fixture_Test.c:16:
unity.framework/extras/fixture/test/unity_fixture_Test.c: In Funktion »TEST_UnityFixture_PointerSetting_«:
unity.framework/src/unity_internals.h:324:130: Fehler: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Werror=pointer-to-int-cast]

In order to fix the build for SandBox and MakefileUnity.mk on a Windows 10 / Cygwin 64 bit system do the following:

from code\\unity.framework\\extras\\fixture\\build\\MakefileWorker.mk delete these lines:
#Kludge to work around cygwin’s not supporting getconf
ifeq ($(findstring CYGWIN, $(shell uname)), CYGWIN)
LONG_BITS = 32
endif

then merge code\\unity.framework\\extras\\fixture\\build\\MakefileWorker.mk
into code\\unity\\build\\MakefileWorker.mk

tests/HomeAutomation/LightControllerSpy.c #includes “LightController.h”. Shouldn’t it #include “LightControllerSpy.h” so it can pick up the declarations in the header? Plus this would have the implementation transitively include LightController.h.

ghenry@ghenry-work:~/src/testing_c/code$ make -f MakefileCppUTest.mk
compiling MockIOTest.cpp
In file included from :0:0:
/home/ghenry/src/cpputest-3.8/include/CppUTest/MemoryLeakDetectorNewMacros.h:45:10: error: ‘void operator delete(void*, size_t)’ is a usual (non-placement) deallocation function in C+14 (or with -fsized-deallocation) [-Werror=c+14-compat]
void operator delete (void* mem, size_t size) UT_NOTHROW;
^
/home/ghenry/src/cpputest-3.8/include/CppUTest/MemoryLeakDetectorNewMacros.h:46:10: error: ‘void operator delete [](void*, size_t)’ is a usual (non-placement) deallocation function in C+14 (or with -fsized-deallocation) [-Werror=c+14-compat]
void operator delete[] (void* mem, size_t size) UT_NOTHROW;
^
cc1plus: all warnings being treated as errors
/home/ghenry/src/cpputest-3.8/build/MakefileWorker.mk:502: recipe for target ‘objs/mocks/MockIOTest.o’ failed
make: * [objs/mocks/MockIOTest.o] Error 1

Should this work?

The output of unity that’s displayed on page 72 is incorrect. It should print 15 tests instead of 16.
The OutOfBoundsLedsAreAlwaysOff test at the top of the page isn’t newly added at that point, just extended by two asserts for LedDriver_IsOff(). Because of that the output on page 73 is incorrect as well. There’re only 17 tests in total.
Weirdly the number of symbols (dots/exclamation marks) printed is the same for both outputs, which is 16 and wrong in both cases.

static void setLedImageBit(int ledNumber)
Will never work. Although ledNumber is changed in the function, this will not get out of the function.

The first sentence of the second paragraph says: “Collaborators can get in the way when is it hard to control their behavior.”
It should say “Collaborators can get in the way when it is hard to control their behavior.”

(change the order of ‘is it’)

The explanation of what a Test Dummy is misspells ‘compiler’ as ‘complier’

“Location 298 of 10301” in the Kindle book — The “Online Resources” URL for Unity (unity.sourceforge.net) is no longer valid.
(Not your problem — the redirect from that URL is broken).

Still, I suggest you use “www.throwtheswitch.org/unity” or else “github.com/ThrowTheSwitch/Unity” instead.

Text uses variables ledAddress and ledsAddress but no such names are define in code so far, there is only address loacal variable of funcion LedDriver_Create.

Second last paragraph on page “When calls to FormatOutput() have been overridden with FormatOutputSpy(), the output can be accessed by a call to FormatOutputSpy_GetOuput().”
FormatOutputSpy_GetOuput() should be FormatOutputSpy_GetOutput()

In figure 20 < should be <>

At the top of the page, “heros” should be “heroes”.

When I’m doing the third step from the section “Where are we?” in chapter "Test-Driving Tools and Conventions:

make -f MakefileCppUTest.mk

Shell shows me what has follow:
compiling MockIOTest.cpp
In file included from :0:0:
/home/user/tools/cpputest/include/CppUTest/MemoryLeakDetectorNewMacros.h:45:10: error: ‘void operator delete(void*, size_t)’ is a usual (non-placement) deallocation function in C+14 (or with -fsized-deallocation) [-Werror=c+14-compat]
void operator delete(void* mem, size_t size) UT_NOTHROW;
^
/home/user/tools/cpputest/include/CppUTest/MemoryLeakDetectorNewMacros.h:46:10: error: ‘void operator delete [](void*, size_t)’ is a usual (non-placement) deallocation function in C+14 (or with -fsized-deallocation) [-Werror=c+14-compat]
void operator delete[](void* mem, size_t size) UT_NOTHROW;
^
cc1plus: all warnings being treated as errors
/home/user/tools/cpputest/build/MakefileWorker.mk:502: recipe for target ‘objs/mocks/MockIOTest.o’ failed
make: * [objs/mocks/MockIOTest.o] Error 1

How can I fix it?

TEST (LedDriver, TurnOnMultipleLeds)

must be

TEST (LedDriver, LedMemoryIsNotReadable)

In the make files (MakefileWorker.mk) is a comment “#BTW: I’m just guessing that mingw is 32 bit only”. This is not correct, or at least there is the mingw64 which provides gcc in both 32 bit and 64 bit versions. I think mingw64 is at least as common as the original mingw.

To run the first example I had to fix this, as well as include <string.h> in SprintfTest.c to get the declaration of strlen();