James W. Grenning - Test Driven Development for Embedded C

Test-Driven Development for Embedded C is hands-down the best book on the subject. This is an amiable, readable book with an easy style that is fairly code-centric, taking the reader from the essence of TDD through mastery using detailed examples. Its a welcome addition to the genre because the book is completely C-focused, unlike so many others, and is specifically for those of us writing firmware.

James skips no steps and leads one through the gritty details but always keeps the discussion grounded so one is not left confused by the particulars. The discussion is laced with homey advice and great insight. Hes not reluctant to draw on the wisdom of others, which gives the book a sense of completeness.

The early phases of a TDD project are mundane to the point of seeming pointlessness. One writes tests to ensure that the most elemental of things work correctly. Why bother checking to see that what is essentially a simple write works correctly? Ive tossed a couple of books on the floor in disgust at this seeming waste of time, but James warns the gentle reader to adopt patience, with a promise, later fulfilled, that hell show how the process is a gestalt that yields great code.

TDD does mean one is buried in the details of a particular method or a particular test, and the path ahead can be obscured by the tests at hand. If youre a TDD cynic or novice, be sure to read the entire book before forming any judgments so you can see how the details morph into a complete system accompanied by a stable of tests.

Better than any book Ive read on the subject, Test-Driven Development for Embedded C lays out the essential contrast between TDD and the more conventional write-a-lot-of-code-and-start-debugging style for working. With the latter technique, were feeding chili dogs to our ulcers as the bugs stem from work we did long ago and are correspondingly hard to find. TDD, on the other hand, means todays bug is a result of work one did ten minutes ago. Theyre exposed, like ecdysiast Gypsy Rose Lees, uh, assets. A test fails? Well, the bug must be in the last thing you did.

One of TDDs core strengths is the testing of boundary conditions. My file of embedded disasters reeks of expensive failures caused by code that failed because of overflows, off-by-one errors, and the like. TDDor, at least James approach to itmeans getting the happy path working and tested and then writing tests to ensure each and every boundary condition is also tested. Conventional unit testing is rarely so extensive and effective.

Embedded TDD revolves around creating a test harness, which is a software package that allows a programmer to express how production code should behave. James delves into both Unity and CppUTest in detail. (Despite its name, the latter supports both C++ and C). Each test invokes creation and teardown routines to set up and remove the proper environment, like, for instance, initializing a buffer and then checking for buffer overflows. I found that very cool.

Test-Driven Development for Embedded C is an active-voice work packed with practical advice and useful aphorisms, such as refactor on green (get the code working first, and when the tests pass, then you can improve the code if necessary). Above all, the book stresses having fun while doing development. And thats why most of us got into this field in the first place.

Youve picked up this book because you are an embedded software engineer. You dont live in the programmers world of multicores, terabytes, and gigaflops. You live in the engineers world of hard limits and physical constraint and of microseconds, milliwatts, and kilobytes. You probably use C more than C++ because you know the code the C compiler will generate. You probqably write assembler when necessary because sometimes even the C compiler is too profligate.

So, what are you doing looking at a book about Test-Driven Development? You dont live in the kind of spendthrift environment where programmers piddle around with fads like that. Come on, TDD is for Java programmers and Ruby programmers. TDD code runs in interpreted languages and virtual machines. Its not for the kind of code that runs on real metal , is it?

James Grenning and I cut our teeth on embedded software in the late 70s and early 80s. We worked together programming 8085 assembler on telephone test systems that were installed in racks in telephone central offices. We spent many an evening in central offices sitting on concrete floors with oscilloscopes, logic analyzers, and prom burners. We had 32KB of RAM and 32KB of ROM in which to work our miracles. And boy, what miracles we worked!

James and I were the first to introduce C into the embedded systems at our company. We had to fight the battles against those hardware engineers who claimed C is too slow. We wrote the drivers, the monitors, and the task switchers that allowed our systems run in a 16-bit address space split between RAM and ROM. It took several years, but in the end, we saw all the newer embedded systems at our company written in C.

After those heady days in the 70s and 80s, James and I parted company. I wandered off into the realms of IT and product-ware, where resources flow like wine at an Italian wedding. But James had a special love for the embedded world, so for the past thirty+ years James Grenning has been writing code in embedded environments such as digital telephone switches, high-speed photocopiers, radio controllers, cell phones, and the like.

James and I joined forces again in the late 90s. He and I consulted at Xerox on the embedded C++ software running on 68000s in Xeroxs high-end digital printers. James was also consulting at a well-known cell phone company on its communications subsystems.

As accomplished as James is as an embedded software engineer, he is also an accomplished software craftsman. He cares deeply about the code he writes and the products he produces. He also cares about his industry. His goal has always been to improve the state-of-the-art in embedded development.

When the first XP Immersion took place in 1999, James was there. When the Agile Manifesto was conceived in Snowbird in 2001, James was there and was one of the original signatories. James was determined to find a way to introduce the embedded industry to the values and techniques of Agile software development.

So, for the past decade, James has participated in the Agile community and worked to find a way to integrate the best ideas of Agile software development with embedded software development. He has introduced TDD to many embedded shops and helped their engineers write better, more reliable, embedded code.

This book is the result of all that hard work. This book is the integration of Agile and embedded. Actually, this book has the wrong title. It should be Crafting Embedded Systems in C because although this book talks a lot about TDD, it talks about an awful lot more than that! This book provides a very complete and highly professional approach to engineering high-quality embedded software in C, quickly and reliably. I think this book is destined to become the bible of embedded software engineering.