This particular story is about applying TDD to a legacy product for a new feature particularly difficult to simulate. The application is a commercial water heater that we wanted to adjust a parameter based on heater duty cycle, i.e. heating on time to off time. Heating cycles may vary from a few minutes to many 10s of minutes. To further complicate the matter we don’t want to react to just the last duty cycle but notice a trend over many duty cycles to categorize it to three possible states; low, medium or normal.

We have bench fixtures with knobs and switches we use for simulating a water heater operation. To test the new feature would mean hours of testing and timing to insure duty cycles were calculated correctly and to verify the proper decision as to the duty cycle state is made.

Unless I wrote flawless code the first time, repeating the tests each time a mistake was found could have meant weeks of development and test time.

Our code is fairly well modularized and uses object oriented techniques even though we are using ANSI C. TDD looked to be the just the thing to help here but because of a number of reasons, it was not practical to do TDD in the development environment used for the project. Taking a “sandbox” approach, using TDD in an Eclipse based tool with GNU C and the Unity test harness, the project was setup in a day and a half. When the duty cycle function was fully developed in TDD it would get ported back to the embedded project for testing. The sandbox approach reduced test time to hours or days of water heater time to just seconds. Following the steps learned at the embedded TDD seminar, I created many more tests than I would have been patient to actually test the old way. This thoroughly exhausted all combination of increasing and decreasing duty cycles and boundary conditions.

Software development took at most two days to pass all the TDD tests. I made many mistakes but found them very quickly. I can’t imagine how frustrating finding the same mistakes on the fixture would have been. It certainly would have taken many weeks. After completing TDD and porting it over to the real target, it passed fixture testing the first time! It was verified by automatic testing at our sister facility before release. The project was reduced from what could have been weeks of frustration to a relatively fun 2 days of development + 1.5 days to set up the sandbox.

This convinced me that we can not only apply TDD to legacy code (albeit in a creative sandbox way), but dramatically shorten development time while more thoroughly testing the code. Did I mention I have only used TDD on a few demo projects before? I am certainly no expert, but excited to become one.