£22.50
FREE Delivery in the UK.
In stock.
Dispatched from and sold by Amazon.
Gift-wrap available.
Quantity:1
Trade in your item
Get a £6.20
Gift Card.
Have one to sell?
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Test Driven Development for Embedded C (Pragmatic Programmers) Paperback – 5 May 2011


See all formats and editions Hide other formats and editions
Amazon Price New from Used from
Paperback
"Please retry"
£22.50
£11.37 £11.52

Frequently Bought Together

Test Driven Development for Embedded C (Pragmatic Programmers) + Making Embedded Systems: Design Patterns for Great Software + Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit
Price For All Three: £83.33

Buy the selected items together


Trade In this Item for up to £6.20
Trade in Test Driven Development for Embedded C (Pragmatic Programmers) for an Amazon Gift Card of up to £6.20, which you can then spend on millions of items across the site. Trade-in values may vary (terms apply). Learn more

Product details

  • Paperback: 352 pages
  • Publisher: Pragmatic Bookshelf; 1 edition (5 May 2011)
  • Language: English
  • ISBN-10: 193435662X
  • ISBN-13: 978-1934356623
  • Product Dimensions: 19 x 2 x 23.5 cm
  • Average Customer Review: 5.0 out of 5 stars  See all reviews (3 customer reviews)
  • Amazon Bestsellers Rank: 240,986 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, and more.

Product Description

Review

""This book is targeting the embedded-programmer-on-the-street and hits its target. It is neither spoon-fed baby talk nor useless theory-spin. In clear and simple prose, James shows working geeks each of the TDD concepts and their C implementations. Any C programmer can benefit from working through this book."" --Michael "GeePaw" Hill, Senior TDD coach, Anarchy Creek Software ""I have been preaching and teaching TDD in C for years, and finally there is a book I can recommend to fellow C programmers who want to learn more about modern programming techniques."" --Olve Maudal, C programmer, Cisco Systems""James is a true pioneer in applying Agile development techniques to embedded product development...this book was worth waiting for. This is a good and useful book that every embedded developer should read.""--Bas Vodde, Author of "Scaling Lean and Agile Development" and "Practices for Scaling Lean and Agile Development," Odd-e, Singapore

About the Author

James Grenning trains, coaches, and consults worldwide. His considerable experience brings depth in both technical and business aspects of software development. James is leading the way to introduce Agile development practices to the embedded world. He invented Planning Poker and is one of the original authors of the Manifesto for Agile Software Development, February 2001.


What Other Items Do Customers Buy After Viewing This Item?

Customer Reviews

5.0 out of 5 stars
5 star
3
4 star
0
3 star
0
2 star
0
1 star
0
See all 3 customer reviews
Share your thoughts with other customers

Most Helpful Customer Reviews

3 of 3 people found the following review helpful By Amazon Customer on 27 Feb 2013
Format: Paperback Verified Purchase
In brief, this is very readable, useful for non-embedded programmers, and has made a tangible difference to the way I work.

Test driven development (TDD) is a programming approach in which you write a unit test prior to writing a function or section of code. You then write that piece of code to make the test pass. Programming then becomes a loop: write test code, write code, refactor, test. Programming becomes a game in which each small step feels like a victory, frustration is hugely reduced, and your code quality improves. The tests help document code, and verify that in changing one element, you haven't broken a previously working element.

I am not an embedded C programmer, but I had heard that this book is an excellent introduction to TDD. There are lots of books about TDD for Java and C#, but, things have been bleak for C and C++ programmers. Not any more.

The book is example driven, with lots of code. It describes an apparently common situation in which embedded programmers have to sit around waiting for their target hardware, which may arrive late in the development cycle; they then embark on a stressful coding cycle of tight deadlines and debugging. The book then advocates a test driven approach: one that is not, or has not been, typical in such environments. Instead of waiting for hardware, it details a path whereby slightly abstracted code is written with associated unit tests (which, happily, also makes the book useful to the non-embeddedly inclined), with the intention of producing code in an advanced and well-tested state prior to introduction to the target hardware.

The book describes two unit test frameworks, which are ideal for the embedded world: one implemented in C called Unity, and a C++-based CppUTest (not to be confused with CppUnit).
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
1 of 1 people found the following review helpful By whaley on 16 Oct 2014
Format: Paperback
I've been writing embedded C for over 30 years, and I was sceptical when someone said "Buy James W. Grenning's book, it will challenge and change the way you think about developing software". But, I was pleasantly surprised, and I couldn't put the book down!

I started reading the book thinking "this is good stuff, I need to try it out", still slightly sceptical as to whether TDD was for me. TDD is mostly one of those "got to experience it to understand it" things, and reading about coding a test unit to test an LED driver sounds on the surface to run the risk of being contrived, but it worked for me, and I was soon hooked on this new way of coding.

James cleverly presents all the material in an easy to read, practical, and problem-lead approach, meaning that he introduces new concepts and ideas just as you are thinking "ah, but what about....", and answered all those burning questions I had along the way such as "yeah, but what about this, and how do you deal with that..."

Since working through James' book, I've managed to successfully implement TDD on a number of my projects, the code that came out at the end was rock solid, I enjoyed the safety net that the growing test harness gave me, and the power that it gave me as a developer to answer questions like "how far through the project are you" and "what is the risk of making this change" suddenly became within my reach. The safety net of the growing test suite meant I could make bold changes to the code with confidence that if I broke something, the test harness had the tested behaviour "locked down" so it would point out exactly what I had missed.

Many people misinterpret TDD as unit testing - I did in the early days too.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
0 of 1 people found the following review helpful By S. J. Merrick on 22 July 2013
Format: Paperback Verified Purchase
If you write in C, which almost certainly means you're in embedded programming, whether you already use TDD or not, buy this book, read it and put it into practice. TDD is no longer suspect; it's been twenty years now, and most people who use it *still* find it valuable. It's time to dip your feet into the water!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Helpful Customer Reviews on Amazon.com (beta)

Amazon.com: 17 reviews
13 of 13 people found the following review helpful
Just what I was looking for 2 Jun 2011
By Jan-Harald Fredriksen - Published on Amazon.com
Format: Paperback
As the other reviews have stated, this is a very good book. I had been looking for a book like this for a while, so I first picked this up in a beta version from the Pragmatic Programmers website.

The two first section give a wonderful introduction to TDD in C. By the end of the second section, Grenning has covered the reasons for doing TDD, looked at available tools, and introduced various methods (spies, test doubles, mocks) for breaking module dependencies during testing. Lots of code examples are included throughout. These two sections were by far the most useful to me. Having been a programmer for a number of years without doing TDD, I needed some convincing, so the "Yeah, but..." chapter was spot on.

The third section (Design and Continuous Improvement) feels a little bit more unfocused. It covers three rather large topics (SOLID design, refactoring, and working with legacy code) that all deserve (and have) whole books dedicated to them. It may be intended as further examples of how to apply TDD, and it does do a fine job of that.

In short, I think this book serves as a very good introduction to the topic. That does not mean, however, that it answered all my questions about TDD. Most of these question revolve around how these techniques scale up to larger projects and teams.
Two examples:
* In Chapter 10 it is stated that "Mocks enforce a strict ordering of interactions, which can lead to fragile tests ...". I would have loved to read some thoughts on when this is likely to occur, possible solutions, etc.
* The LED driver example is a good example, but it isn't immediately obvious how this approach would scale to larger hardware blocks (say, a co-processor).

Also, performance concerns are mentioned a few times, but may have had deserved a little more space. For example, in Chapter 3 it is stated that abstract data types are hidden (only forward declared in the header) from the caller. In its naïve form, this does not allow for inlined function calls, which can still be a performance problem on some platforms. A discussion on how to deal with issues like this would have been useful.
58 of 74 people found the following review helpful
There is nothing on embedded programming 5 July 2011
By Maduranga - Published on Amazon.com
Format: Paperback
For those who don't want to go through the entire review, here's the summary: Despite including "Embedded C" in the title, this book does not include anything at all particular to embedded programming. This is an introduction to TDD book, and in my opinion not such a good one either.

Here's the breakdown:

I'm a firmware developer so I picked this book up because, (1) I wanted to learn TDD and, (2) I wanted to learn how to apply it to embedded programming. So I thought I can kill two birds with one stone buying this book. Sadly this book does a very poor job at both. In my opinion, anybody picking up a book on TDD is not a beginner in programming. This is a place the book gets things wrong first. It is unnecessarily overly verbose at times, explaining simple things duplicating before and after code snippets. On the other hand, some important points are not explaining enough. For example, the only two points I found useful in this book was link-time substitution and function pointer use. These are not new to a programmer, but I felt are very useful when applying TDD, especially when working with existing legacy code (which most of us will have to work on one time). But the book doesn't explain them in detail (as it does other very trivial topics).

And for the biggest dissapointement, this book has nothing special for embedded programming. The closest the author gets to an embedded system are the two exaplme projects he presents in the book, the LedDriver and the LightScheduler. These two are very simple to qualify as an embedded system, because usually an embedded system is much more complex than turning on an LED at the given time.

An embedded system program differs from a normal program in many ways. For example, an embedded system has to deal with interrupts, exceptions, DMA, memory accesses, wait states, serial/link port communications, synchronization, processing power, etc. There is absolutely nothing about this in this book. The only place you find anything about embedded is when author tells some "stories" about embedded projects and in appendix where a very short explanation to running on Linux and uC OS is presented.

Overall the book is disappointing because it doesn't deliver to its title embedded C. And then, even as a book on introduction to TDD, I cannot say I'm very impressed. It is very verbose when it clearly doesn't need to be, and not verbose enough when it should be.

I hope the author revises the book and put more embedded programming related contents because at this state the books' contents doesn't do justice to the title.
13 of 15 people found the following review helpful
The word is out. TDD works for C! 30 May 2011
By Bas Vodde - Published on Amazon.com
Format: Paperback
Test-Driven Development for C does exactly what the title promises you. It describes how to do Test-Driven Development in the C programming language. People have argued that Agile development is for modern projects, but not embedded ones. Test-Driven Development can work in Object-Oriented languages but not in programming languages like C. James proves this wrong by showing how you can test-drive you code in C.

The book consists of 4 different parts of which the last part are the appendices, which I'll skip in this review. The first part covers the basics of TDD, the second part discusses how to test a module that has dependencies with other modules. The third part discusses the design aspects of TDD.

The first chapter introduces the concept of test-driven development after which the author continues introducing the two unit test frameworks used in the book: Unity and CppUTest. In the third chapter, the LED example is introduced and used to clarify TDD. The fifth chapter dives in the embedded space and discusses dual targeting and other embedded C techniques. The first part ends with an summary of objections that people typically have against TDD and an counter argument for each other them.

The second part continues with a more complicated example (light automation system). This system has multiple modules and thus each of the modules need to be separated to be able to test it. Chapter 8 discusses link-time substitution and chapter 9 then dives into how to do this at run-time. Chapter 10 introduces Mock objects by first writing one by hand, and then introducing CppUTest mocking and CMock.

The last part dives into design. In the end, TDD is a design technique, so a TDD book couldn't do without diving deeper into design. Chapter 11 introduces the SOLID OO principles and shows that OO principles are valid principles... even when your programming language is not an OO language, such as C. Chapter 12 introduces refactoring in C and the different code smells that are common triggers to refactor. Chapter 13 covers how to deal with legacy code and, the last chapter, covers patterns for writing good (and bad) tests.

James Grenning's TDD is C is a very much needed book. Embedded software statistics in the world show that the amount of embedded software in the world is growing fast. Most of this embedded software is still done in C. The embedded software community hasn't learned the new development techniques that have changed application development the last 10 years, such as TDD. James finally introduces these important changes in development style to the embedded community. His book is easy to read, funny, and useful. Most of all, it was just needed! I have been doubting between 4 and 5 stars (4 as it does what it says, 5 because it is the first book of its kind) and decided to stick with 5 stars. Well done, James :)
7 of 8 people found the following review helpful
Changes how I develop 28 April 2011
By Matt Wilbur - Published on Amazon.com
Format: Paperback
This book is fantastic. If you do development in C for embedded work (or C++ for that matter), buy it. Go on. Click the "Add to cart" button right now. I'll wait. Done? Good.

As a backgrounder, I have been doing engineering work for almost 10 years now, but have only been doing embedded software for a little over 2.5. In that time, I have been trying to find a way to develop that made it easier to develop from a blank slate. I had seen designs I had liked, but I just didn't know how to create them myself. "Test-Driven Development for Embedded C" is, without a doubt, what will help me get there.

TDD was appealing to me, but I despaired because I was doing embedded work. I had drivers to work on, dammit. I couldn't use Java, or Smalltalk, or Ruby. I think it was a Google search that landed me on the Pragmatic Programmer web page for Test-Driven Development for Embedded C. "Is this for real?", I thought. Yes it was. Unfortunately, it wasn't in print yet. But, there was the Beta Book. I more than willingly shelled out and worked from that.

I admit, it collected dust for a while as I worked on this thing or that, where I was essentially working with other people's code and I didn't think I could make use of the book (I know I'm wrong about that now, but I digress). My current project, though, was going to be my own and fairly complex. I needed something to reduce my stress. So, I went back to James' book. I ate it up steadily until I was about 70% through, and I decided to take the leap. I've been using TDD (with diligence, on the average) for about four weeks now and I can't imagine coding any other way.

Admittedly, I do some things a little differently than the book does, but this book is my cornerstone. I worked through the examples myself (peeking at the book's downloadable code from time-to-time), up to and including the Mock Objects chapter (Driver development off-hardware? Insane!). After that, I could mostly get by with reading.

James does a great job at taking the reader from a standing start through some fairly realistic examples. All the code is on the book's website, so you can always grab it, but do yourself a favour and work through it from scratch. Yes, getting going will be bumpy, but there's no teacher like experience. In addition, James himself is available on the book's forum on the PragProg website, as well as on the Agile Embedded Yahoo! group where he will answer questions. Others will too. People get fanatical about this stuff, and I now understand why.

I have been developing one module using TDD for a couple of weeks now, and I've never been more confident or proud of my C code before.
4 of 4 people found the following review helpful
Not just informative, but transformative. 28 July 2012
By Eric Ross - Published on Amazon.com
Format: Paperback
I read many books on software test and there are two things that make this book unique and worth having on your bookshelf. First, it focuses on the unique needs of embedded firmware. Secondly, it does it using an approach that builds one capability upon another capability in working with this especially difficult type of testing.

I work with about 300 other firmware engineers on a code base consisting of over 1 million lines of code and I, frankly, was a bit skeptical about being able to use TDD in such an environment with the huge base of legacy code that we have to manage. As the lead for firmware quality, I had to dramatically shift the mindset on how test was done on our code base from a traditional toss it at QA until it doesn't get tossed back to an R&D owned and executed test environment. Many of my initial presentations were based on Chapter 6 "Yeah, but..." which is one of the best synopsis of objections I have heard over the years to doing this kind of testing on embedded systems. After demonstrating the technique to some open minds, I handed over the book and they ran with it. We now have some very enthusiastic champions for transforming our development processes and Test-Driven Development for Embedded C is a key contributor.

It was clear that James W. Grenning attempted to keep the depth light enough that one could read through and start using the techniques very quickly. For your test leads who hunger for more I recommend supplementing this with a more in-depth book: Working Effectively with Legacy Code
Were these reviews helpful? Let us know


Feedback