An email came in recently discussing TDD (Test Driven Development) for Hardware development, and requested an example. I wrote this back and have made it available here, too:
“One example of TDD from our project was the emissions system. We started with a user story; in our case a post-it note on the wall; which said “As a user I can drive a car emitting less than 100g of CO2 per 100km driven so that I can reduce climate change.”
We then bought an emissions test machine and started developing and iterating emissions systems in order to pass the test provided by the emissions test machine. In this way, we started with a failing test (100g of CO2 per 100km driven). Of course, the test was failing as we didn’t have a car at all at that point. We acquired a test fixture to let us quickly and inexpensively (time and money, but most importantly for us low-frustration) check if the test was passing.
All of our work is phrased in stories that have 3 parts – a role, a goal, and a reason. In addition to the story ‘title’, stories also need to include concrete acceptance criteria. In the example above, the role is “user” – someone who drives the car. The goal is clearly stated, as is the reason for wanted to accomplish that goal.
Here is another story: “As a user I can drive 100 miles at 100 mpg so that I can save money on gas compared to standard cars.” That story isn’t “done” until a user actually climbs into the car and drives the car 100 miles at 100 mpg.