This week I spent three days with James Grenning, and ten other gentlemen, to be educated in Test Driven Development for Embedded C at the LeanDog boat in Cleveland Ohio.
For some background Jack Ganssle did a two part interview with Mr. Grenning last summer [2010], on the subject of TDD in Embedded Development:
A majority of the course is based on James' about to be released new book [May 2011] Test Driven Development for Embedded C, and a lot of insights drawn from his background in agile development methods, James was one of the signers of the Agile Manifesto and Embedded Systems.
The premise of TDD is that you write the tests for the code that needs to be created, before the first line of code is ever written. How can you possible know if your code is bug free if you can not figure out how to write a test for it? As each small test case is written, you watch it fail, then write the code that is being tested, then run the test again to see that it passes. In the method of design from the top down and build from the bottom up, our products now are being built from a solid foundation of small tested functions, rather than on untested code full of unknown bugs, sinking in the Big Ball of Mud.
More thought is put into the upfront requirements (the what of the product and how it gets validated) and specifications (the how the product gets built and verified), rather than seeing the schedule slip month by month trying to get all of the bugs out of the code by heroic effort at the end of the development process.
In the words of Confucius: "I hear and I forget. I see and I remember. I do and I understand." A large part of the class was hands on examples of writing tests for supplied examples, and then seeing how our version compared to that written by James. Some of the examples had deliberate bugs and build traps that those new to TDD would fall into, such as a module being pulled from a library causing a name clash when a header file gets edited. There is the real production code, test code, and sometimes fake or 'mock' code. The 'mock' code takes the place of some item that does not yet exist or would be to time consuming to test. If things were not set up correctly the fake/mock code would collide with the real production code. Myself in this one case I still think I prefer using Makefiles and different build directories rather than James' linker library method. Neither is right or wrong, but a mater of taste and style.
All of the tests were run using the test harness cppUTest, which can test plan old C code and C++ code.
TDD is not just for brand new projects, it is equally suited to cleaning up the tangled mess that some legacy code has become after years of changes by different people. Part of the class was on 'refactoring' and the difference between that and redesigning the code, and how to apply the test cases. Pick out a single area of code with the end target to be a single well tested function. When tests have been established for the existing code the code is incrementally moved, in small steps, to get visibility points for more tests, until the code can be replaced with new tested clean code. James and the book are far more eloquent at describing the process than I have been here. James' blog and papers, several covering Embedded Systems, are a great resource to take advantage of, for example: Legacy Code Change - a Boy Scout Adds Tests.
One of the other tools mentioned, but not actually used in class is FitNesse acceptance testing framework.
Alas TDD is not a panacea for all of our collective code problems. It may not cover integration issues such has multi-threading race conditions [Use the Erlang principles of modify nothing and everything is a message, and threading issues vanish, even on MultiCore parts], it also might not find issues that are dependent on the target hardware integer size, when the host and target differ, unless the tests can also be run on the target, which is strongly recommended when possible.
At lunch Jon Stahl, our gracious host for the three day class, the owner of LeanDog, gave us lunch time talks, such has the one on Agile & Lean From The Top Down: Executives Practicing Agile and Seeing Constraints, Kanban Explained. Take a look at the slides to see the LeanDog Boat, the floating office, and the Lean Dog's themselves, Otis and Iggy. Talk to Jon about improving your bottom line in your business area and/or your software development area.
Also it is always good to get out, as sometimes you learn things at lunch that you would never know about such as The Tau Manifesto on how Pi is (still) wrong [YouTube Video]...
If you have the opportunity to take James TDDinC class when he is in your area, make the time for it, and if you are in Cleveland stop and say hello to Otis and Iggy, and sign up for some traning.
For some background Jack Ganssle did a two part interview with Mr. Grenning last summer [2010], on the subject of TDD in Embedded Development:
A majority of the course is based on James' about to be released new book [May 2011] Test Driven Development for Embedded C, and a lot of insights drawn from his background in agile development methods, James was one of the signers of the Agile Manifesto and Embedded Systems.
The premise of TDD is that you write the tests for the code that needs to be created, before the first line of code is ever written. How can you possible know if your code is bug free if you can not figure out how to write a test for it? As each small test case is written, you watch it fail, then write the code that is being tested, then run the test again to see that it passes. In the method of design from the top down and build from the bottom up, our products now are being built from a solid foundation of small tested functions, rather than on untested code full of unknown bugs, sinking in the Big Ball of Mud.
More thought is put into the upfront requirements (the what of the product and how it gets validated) and specifications (the how the product gets built and verified), rather than seeing the schedule slip month by month trying to get all of the bugs out of the code by heroic effort at the end of the development process.
In the words of Confucius: "I hear and I forget. I see and I remember. I do and I understand." A large part of the class was hands on examples of writing tests for supplied examples, and then seeing how our version compared to that written by James. Some of the examples had deliberate bugs and build traps that those new to TDD would fall into, such as a module being pulled from a library causing a name clash when a header file gets edited. There is the real production code, test code, and sometimes fake or 'mock' code. The 'mock' code takes the place of some item that does not yet exist or would be to time consuming to test. If things were not set up correctly the fake/mock code would collide with the real production code. Myself in this one case I still think I prefer using Makefiles and different build directories rather than James' linker library method. Neither is right or wrong, but a mater of taste and style.
TDD is not just for brand new projects, it is equally suited to cleaning up the tangled mess that some legacy code has become after years of changes by different people. Part of the class was on 'refactoring' and the difference between that and redesigning the code, and how to apply the test cases. Pick out a single area of code with the end target to be a single well tested function. When tests have been established for the existing code the code is incrementally moved, in small steps, to get visibility points for more tests, until the code can be replaced with new tested clean code. James and the book are far more eloquent at describing the process than I have been here. James' blog and papers, several covering Embedded Systems, are a great resource to take advantage of, for example: Legacy Code Change - a Boy Scout Adds Tests.
One of the other tools mentioned, but not actually used in class is FitNesse acceptance testing framework.
Alas TDD is not a panacea for all of our collective code problems. It may not cover integration issues such has multi-threading race conditions [Use the Erlang principles of modify nothing and everything is a message, and threading issues vanish, even on MultiCore parts], it also might not find issues that are dependent on the target hardware integer size, when the host and target differ, unless the tests can also be run on the target, which is strongly recommended when possible.
At lunch Jon Stahl, our gracious host for the three day class, the owner of LeanDog, gave us lunch time talks, such has the one on Agile & Lean From The Top Down: Executives Practicing Agile and Seeing Constraints, Kanban Explained. Take a look at the slides to see the LeanDog Boat, the floating office, and the Lean Dog's themselves, Otis and Iggy. Talk to Jon about improving your bottom line in your business area and/or your software development area.
Also it is always good to get out, as sometimes you learn things at lunch that you would never know about such as The Tau Manifesto on how Pi is (still) wrong [YouTube Video]...
If you have the opportunity to take James TDDinC class when he is in your area, make the time for it, and if you are in Cleveland stop and say hello to Otis and Iggy, and sign up for some traning.
Posts
