on 27 February 2013
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.
on 16 October 2014
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. James deals with this early on in the chapters and re-enforces the point throughout with real examples. TDD is all about making the tests drive out the functionality, in a way that also tests the test harness. In this book you will gain real experience of this elegant but important fact: the fact that if you write a test harness to "unit test" your code, all you've done is add more untested code to your code base.
RED, GREEN, REFACTOR! - now one of my core "mantras" that I say to myself as I'm coding new functionality.
In particular, the first real project I developed using the ideas I learnt from James' book was a fully functional multi-core processor simulator. I added tests for each of the instructions one by one, and let the TDD method "drive out" the functionality of the memory units, the bus, the register file, the peripherals, and everything else, just as it was needed in the design. I knew through coverage tools that the simulator had a really high test coverage, and when I ran a real industrial program on the simulator for the first time, it worked perfectly, first time. It takes a lot to impress me, but I was very impressed with the results.
I would say from experience that you have to have a little bit of faith to take on TDD and that it will improve your development cycles if you engage with the concepts properly. Writing tests seems like a slow process sometimes: although this is balanced by regularly adding and running new tests and getting instant feedback. You will feel at times that "It must be quicker to just write some code", but the payback in the long term of the added safety of the test suite, the ongoing progress reports of how you're doing, the fact that your test suite is tested, you have only the code you need to make something work, and you can make bold sweeping changes with confidence, far outweighs this.
I highly recommend James' book, it will change the way you develop software, forever. It did for me, anyway. I challenge you as a professional software engineer, to give this book the time of day and the place on your desk that it deserves.
on 22 July 2013
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!