Repair your broken windows!

Whein Warren Hein
Embedded Software Engineer, Cisco

I was first introduced to TDD through James presentation at the Embedded Systems Conference several years ago. The notion of fully testing your code throughout the development process enthralled me. Working in the networking field, where prototype equipment is a shared resource and not always accessible, and the build/test/validate cycle frequently runs in the tens of minutes, our code base was littered throughout with code blocks known to need refactoring, but due to the cost of the regression cycle, would never be addressed. The broken window syndrome would continue as each new hardware product was introduced.

I was able to integrate the CppUTest harness that James co-developed into components in our code base, and along with several tools: gen-xfakes, fake-function-framework, was able to wrangle several of our modules into the test harness. By building unit tests to validate the existing behavior, we were able to safely refactor these problematic areas and make them adaptable to future hardware additions. The seconds-long feedback loop was extremely beneficial in not only ensuring our changes worked as intended, but allowed for experimentation on additional improvements which would not be attempted if we were following the traditional means of validating changes on the actual hardware.

Starting TDD on a new project is a much more easy endeavor, but integrating it into an established code base requires some time and effort to do so. The effort is worth it, and the training that James provides will help get you on your way.

All Stories
We invite you to submit your own story about TDD or Agile for Embedded System Development.
  • Wingman Alumni can sign into their account then return our stories page to add your story.
  • Others, contact for access to add your story.
  • Don't feel like you need to give us a plug (thanks in advance if you do). This is about your story.