Another day without Test-Driven Development means more time wasted chasing bugs and watching your code deteriorate. You thought TDD was for someone else, but it's not! It's for you, the embedded C programmer. TDD helps you prevent defects and build software with a long useful life. This is the first book to teach the hows and whys of TDD for C programmers.
TDD is a modern programming practice C developers need to know. It's a different way to program---unit tests are written in a tight feedback loop with the production code, assuring your code does what you think. You get valuable feedback every few minutes. You find mistakes before they become bugs. You get early warning of design problems. You get immediate notification of side effect defects. You get to spend more time adding valuable features to your product.
James is one of the few experts in applying TDD to embedded C. With his 1.5 decades of training, coaching, and practicing TDD in C, C++, Java, and C# he will lead you from being a novice in TDD to using the techniques that few have mastered.
This book is full of code written for embedded C programmers. You don't just see the end product, you see code and tests evolve. James leads you through the thought process and decisions made each step of the way. You'll learn techniques for test-driving code right next to the hardware, and you'll learn design principles and how to apply them to C to keep your code clean and flexible.
To run the examples in this book, you will need a C/C++ development environment on your machine, and the GNU GCC tool chain or Microsoft Visual Studio for C++ (some project conversion may be needed).
Did you know you can trade in your old books for an Amazon.co.uk Gift Card to spend on the things you want? Visit the Books Trade-In Store for more details. Learn more. |
Book Description
Frequently Bought Together
Product details
Would you like to update product info or give feedback on images?
|
More About the Author
Discover books, learn about writers, and more.
Product Description
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.
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
What Other Items Do Customers Buy After Viewing This Item?
Customer Reviews
Most Helpful Customer Reviews
By Michael
Format:Paperback|Amazon 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). The latter is reputed to be accessible for C people. I worked through the examples/exercises with the GoogleTest C++ framework instead: the material is certainly transferable.
The book is split into three parts: the first serves as an introduction to TDD, the second details use of techniques to replace components with dummy objects, and the third discusses code design, refactoring (making code cleaner: removing duplication; changing to a more understandable form), and writing tests for existing code bases.
For programmers who haven't been exposed to TDD before, such as me, it is a life-changing read.
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). The latter is reputed to be accessible for C people. I worked through the examples/exercises with the GoogleTest C++ framework instead: the material is certainly transferable.
The book is split into three parts: the first serves as an introduction to TDD, the second details use of techniques to replace components with dummy objects, and the third discusses code design, refactoring (making code cleaner: removing duplication; changing to a more understandable form), and writing tests for existing code bases.
For programmers who haven't been exposed to TDD before, such as me, it is a life-changing read.
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com:
4.6 out of 5 stars
13 reviews
8 of 8 people found the following review helpful
4.0 out of 5 stars
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.
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.
39 of 52 people found the following review helpful
2.0 out of 5 stars
There is nothing on embedded programming
5 July 2011
By Maduranga Liyanage
- 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.
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.
10 of 12 people found the following review helpful
5.0 out of 5 stars
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 :)
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 :)
›
Go to Amazon.com to see all 13 reviews
4.6 out of 5 stars
Were these reviews helpful?
Let us know
Listmania!
|
|
Look for similar items by category
Feedback
- Would you like to update product info or give feedback on images?
- I am the Author, and I want to comment on my book.
- I am the Publisher, and I want to comment on this book.
|
