Hey, do you like TDD? Maybe you, like me, think it’s the greatest thing since automated unit tests. Maybe you embrace the tried-and-true red-green-refactor development cycle instead of the code-fix-fix-debug-fix-really?-fix-FINALLY development cycle. Or maybe you’re not there yet. Maybe there’s some jerk on your team who is keeping TDD out of his codebase and you need ammunition to convince him otherwise. Regardless, you know there’s some merit to this whole ‘test-driven’ thing.
But what about embedded development, with its interrupts, event loops and watchdog timers; cramming as much as you can into as few bits as possible, it doesn’t seem like there’s room to test drive your code. As a result, your codebase becomes a cyclomatically complex rat’s nest of tangled ifs and whiles.
Well, just because you’re doing embedded work doesn’t mean you can’t TDD. With a few guidelines and a couple of shifts of perspective you can apply TDD to your embedded project. Not only do you get all of the benefits of TDD, but there are also benefits that are unique to the embedded experience!
