TDD Tools

Using TDD for firmware in C can be quite laborious. Creating a new module requires at least steps like:

1. Create a test .c file
2. Add created test to test build
3. Create implementation .c file
4. Create implementation .h file
5. Add implementation to production build
6. Add implementation to previously created test build
7. Create fake object(s) to make the test build to pass
8. Add fake object files to test build

When you adapt the habit of testing everything you quickly get bored repeating these tasks. You end up looking for tools to automate this repeating work. At least this is what you should end up doing, and not giving up.

Atomic Object has created tools in Ruby to do the trick and some. At ESC2007 they demonstrated their tools and already gave the tools on CD, but there still was some minor problems getting the tools to build. Now they have released their tools as open source and fixed the small problems in the earlier distribution. In Summer Issue of Methods & Tools is an article elaborating Atomic Objects approach to agile firmware development infrastructure. Highly recommended starting point, and offers also a path for advanced testing.

Just tried out the package that is now available from their site - Worked like a charm!

Tools do really not need to be complex to make a difference, propably quite the opposite holds. We made file templates and bunch of scripts running sed to replace key words to automate C unit testing steps. We learned this from James Grenning's CppTestTools. From Atomic Object's package we adapted their simple unit test framework Unity. We stripped it down even further, and also mixed it up with the idea of different outputters libraries, like in Embedded Unit. We also adapted their idea of automated mock object creation, but ended up writing similar tool in Python (basically because we wanted to fully understand what we are doing). All our tools are tuned for our use and constantly evolving, but I think towards similar solution as already in use by Atomic Object, but in step-wise manner. We believe that you need to understand the reason, give it the context, for any new skill or practice in order to make it truly work.

Wrap It Thinly

The major concern about TDD in firmware development I hear is the hardware relation.

-"We don't have hardware to run the code in."
-"Every part of the code is hardware dependant."

I noticed I wrote about these approximately a year ago for the first time (I, II, and III). That was more on the theoretical side. This time I have a bit more experience on the subject. We have found Alistair Cocburn's article on hexagonal architecture valuable in philosophizing this issue. Many firmware developers are not familiar with design patterns, but a good starting point is above mentioned article. Writing adapters for your hardware, grouping them to ports, keeping the number of them low, and only allowing them to be responsible for the lowest-level of hardware interfacing, will help you isolate hardware dependant parts. Here is a picture of hexagonal architecture for the case project we are working on.




Then there is a philosophical issue of testing the adapters, or wrappers. In many cases binary input/output handlings are just like accessors, getters and setters. In TDD literature it is generally agreed that these do not need unit tests. When writing hardware wrappers we need to think a bit harder. We could understand the unit tests for hardware wrappers as our firmware/hardware interface specification. Then for sure it makes sense to write these tests. My thinking goes along with "to be able to judge what to unit test and what not to unit test, you have to be able to unit test everything".