This short paper describes how TDD is used to make concrete progress on embedded software before there is any hardware.

Progress Before Hardware Introduction

A common problem facing embedded software engineers is the concurrent development of hardware and software. The embedded software engineer does not have a test bed for their work often until late in the project. I have seen too many project plans that show an integration and test phase late in the project where hardware and software are brought together. Those integrations usually end up turning into seemingly endless debug sessions. We may tell ourselves that this project will be different, that we can integrate, test and ship in two weeks. But we’d be kidding ourselves.

Embedded systems expert Jack Ganssle says “The only reasonable way to build an embedded system is to start integrating today... The biggest schedule killers are unknowns; only testing and running code and hardware will reveal the existence of these unknowns.”[GANSSLE] Jack goes on to say that “Test and integration are no longer individual milestones; they are the very fabric of development.”

Does the lack of the target platform mean we cannot test our code? Does that keep us from following Jack’s advice and the advice from the agile development community? The answer to these questions is a resounding “No!”. In this article I’ll describe how to make progress prior to hardware availability.

For the full story click here:Progress Before Hardware