First Exposure to TDD

I first learned about unit testing and Test Driven Development nearly 20 years ago at a software development conference in California. The person presenting (alas I do not remember who) used the phrase: “Test driven development gives you COURAGE.” At the time I was a principle software engineer and architect for a large consumer electronics company. As mass-production deadlines approached, we lived in a state of extreme caution (dare I say fear), requiring double code reviews for each commit and relying heavily on our rigorous quality assurance team to prevent bugs from reaching the factory. Debug Later Programming was the standard process. We were successful, but I knew we could do better. Sadly, despite being motivated by the presentation, we were unable to introduce unit testing into our large legacy code base, a code base incorporating software and libraries from multiple partners around the globe. It just seemed too intractable.

First Experience with TDD

Fast-forward a few years and I found myself working on a C#/.Net backend service for a small startup. This was my first taste of TDD style development, and I immediately loved it. With only two people on the engineering side and no formal QA, this software stack required a TDD approach. However, as I whipped out unit tests in this domain, I kept thinking about my first-love: embedded software. How is this approach possible with C or C++? Given the advanced mocking features we were using in C#, I did not see how it would be possible in a C or C++ environment.

TDD for Embedded C and C++

Following my C# experience, I transitioned to an independent software consultant role focused on my first love: embedded software and firmware. The presentation from nearly 20 years ago still delivered motivation while my recent C# TDD involvement delivered practical unit testing experience. I was about to lead a firmware project for a device with some safety concerns. However, it was not yet clear to me how to drive a C++ based firmware project using TDD. It was at that exact moment that Grenning’s "Test-Driven Development for Embedded C" book came into my life. I was already motivated. I had related experience. Now, thanks to Grenning’s book and the associated CppUTest framework, I had the necessary tools for my target domain. Over the coming year I drove my first firmware project using Grenning’s written guidance, trained another engineer on TDD to help on the project, and successfully delivered reliable firmware to our customer.

Conclusion

To date, I have now worked on three TDD driven firmware projects and have recently started adding unit tests to a legacy project. I love it and I love the courage TDD brings when it is time to release firmware. My thanks to Grenning for helping engineers like me up their game and avoid excessive Debug Later Programming. -- Thank you James!

Matthew Eshleman -- Services