FullOnTddForEmbedded

Slides

The presentation foils are here: File:Full-OnTDD.pdf

On quite a few of the student machines, executing the tests using rake caused a noticeable "hesitation" for up to half a minute before the results started to emerge. The reason for the slow response has not been discovered. In one case it seemed to improve when certain network drives (which were inaccessible) were disconnected.

Test Driven Development lived up to its name - the API to the alarm device was changed as a result of needing to test initialisation with an invalid register pointer.

It is very important to remember to take BABY STEPS. All too easily you can get tempted to add several bits of functionality at once "because you know you're going to need them in the next test case". Then when something breaks you have more retracing of steps to do.

It was useful to see a few alternative unit test frameworks being applied in anger. It's too easy to specialise in just one and therefore never to experience the advantages / disadvantages of other contenders.

It was useful to go through the low-level steps of configuring the environment and creating the first runnable test. So often you are left clueless when downloaded trial software doesn't work as expected.

The Boost test library probably makes it easier to get going than CppUTest does. But this might have been a consequence of electing to use Eclipse's built-in C++ builder in this exercise.

More than in Unity, it was very easy to run into segmentation faults while executing the compiled and linked unit tests. When this happened, there was no clue as to the reason.

In some cases, running the executable under the debugger (which theoretically should never be necessary if doing TDD properly) revealed a non-initialised pointer. In other cases, it turned out that e.g. the debug build of the test project had been linked to the release build of the production project under test. It's very easy to get this messed up and the usual cure is to turn off automated builds, clean all projects and rebuild each configuration.

Should you run the unit tests on the target hardware? Emphatically yes - you would be surprised how many of them break due to invalid assumptions about the processor architecture, addressing constraints or the configuration of the target environment (e.g. timezone information).

Mocks are a very good way to specify requirements on some component supplied by another team.

 + TemperatureSensor
   + src
     + MicroSecClock.h
     + MicroSecClock.cpp
 + TemperatureSensorTest

   + src
     + MockMicroSecClock.h
     + MockMicroSecClock.cpp
     + MockMicroSecClockTest.cpp