Having worked with both C and embedded systems for a major of my professional time I have always found it interesting to apply different software development methodologies and practices in an embedded environment.

One such practice is test driven development (a.k.a. tdd).

Often, I’ve heard the excuse that various ideas can not be applied to an embedded environment just because it is an embedded environment.

This reasoning is something that I’ve always found a bit odd since, after all, embedded systems are man made, i.e. designed by man and not designed by nature.

So, as I see it, the only thing preventing us from doing so is our own willingness to it.

It is my experience that a majority of embedded systems testing requires running tests on target hardware which reduces the development speed.

One result of introducing test driven development in an embedded environment would probably be different design, a design that would allow us to conduct testing without the need for the target environment.

It would question how we have designed our system and this might offend some more ”senior” people that have preconceived ideas of what ”good” design it.

James Grenning, author of ”Test Driven Development for embedded C”, continues to produce interesting material that shows that it is fully possible to conduct unit testing in an embedded environment. He recently published a number of articles on the topic ”Unit testing RTOS dependent code” (1,2,3) that shows how testing can conducted by mocking the RTOS and using test double functions.

These articles shows us that there are alternative ways to design and conduct testing in an embedded environment.

What do you think? Is this the way to go when testing embedded systems? Is it even related to embedded systems only or is this also applicable in desktop environments? Leave a comment!