- Taschenbuch: 352 Seiten
- Verlag: O'Reilly UK Ltd.; Auflage: 1 (3. Mai 2011)
- Sprache: Englisch
- ISBN-10: 193435662X
- ISBN-13: 978-1934356623
- Größe und/oder Gewicht: 19 x 2 x 23,5 cm
- Durchschnittliche Kundenbewertung: 1 Kundenrezension
- Amazon Bestseller-Rang: Nr. 15.666 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
Test Driven Development for Embedded C (Pragmatic Programmers) (Englisch) Taschenbuch – 3. Mai 2011
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre E-Mail-Adresse oder Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Mehr über den Autor
""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
Über den Autor und weitere Mitwirkende
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.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
In diesem Buch(Mehr dazu)
Als passende Ergänzung zu diesem Buch ist das umfangreiche Buch "Working Effectively with Legacy Code" anzuraten, welches bei Refakturierungsaufgaben noch wesentlich detaillierter vorgeht.
Dieses Buch sollte bei jedem C/C++ Entwickler auf dem Schreibtisch stehen. 5 Sterne.
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta)
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.
* 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.
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.
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 :)
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
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.