Corporate Trainings

Embedded Test Driven Development (TDD)

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.” Test Driven Development is a technique that concurrently develops automated unit and acceptance tests and the working code that satisfies those tests. This technique was developed in the non-embedded world. Can embedded developers successfully adopt the practice for the development of embedded software? I think so and this paper outlines a variation of TDD for embedded development. TDD is usually used with Object Oriented languages, although it can be used with procedural languages such as C. Development Environment and Execution Environment In embedded systems the development environment usually differs from the target execution environment. Development systems are usually standard off the shelf products. Target systems are custom, limited in availability, expensive and usually shared by the development team members. I’ve seen prototype hardware systems costing over $1 million. This results in the engineering team having a many to one ratio of developers to target machines. This means sharing and sharing means waiting. Waiting kills productivity. Even with access to target hardware, development time is slowed whenever we test on it. Downloading and running in the target takes time, and it’s a difficult and expensive environment to design it