I’d like to share a pretty good TDD experience I had recently with a moderately large embedded project (32bit about 130k). This example will show that TDD pays off big time even when you have an old project with only about 50% of its code covered with unit tests. I was tasked with taking out a clunky old “write this while I wait” NVM driver and replacing it with a shiny new “write this while I boogie” NVM driver.
First I had to resolve a couple of entanglement issues with a haphazardly concocted CAN driver and a painfully ugly bootloader. But once that was done, I was basically able to throw out the old and bring in the new. I then proceeded to handle basic issues to get the project to compile. Now up to this point there is no difference between TDD and not. Once the project could compile the question became: “How do I know that this is going to work — that this makes sense?”
Without unit testing and TDD, I’d have to walk through the code finding things that don’t work or don’t make sense one at a time — not a simple or quick process. This is an old project that I’m fairly new to. In certain cases I’d have to “deep dive” and understand what sections of NVM need to be saved and under what circumstances. The problem is not nearly as great with tests already in place. With TDD I run my tests and my tests tell me exactly where the problems lie. I’ll still have to walk through the code at times as a sanity check, but now I can see my problems all at once and strategically annihilate them. Wu who! I can’t get over how big of a difference this makes. It’s been a reaffirmation of how TDD can make even bad projects feel better.