Summary

Steve Branam contrasts system-level acceptance tests with unit-focused TDD, showing how each practice helps protect behavior and enable safe change in legacy and embedded firmware. The post explains when to rely on acceptance tests, when to use TDD, and how to combine them with CI and hardware test strategies.

Key Takeaways

• Differentiate acceptance tests (system/behavior-level) from TDD (unit/design-level) and know the goals of each.
• Use acceptance tests as characterization tests to lock down observable behavior before refactoring legacy firmware.
• Apply TDD to drive unit design, isolate logic from hardware, and produce fast, focused tests that enable refactoring.
• Integrate acceptance tests and unit TDD into CI, using emulation or HIL where needed to catch regressions early.

Who Should Read This

Embedded firmware engineers and team leads working with legacy code or building test strategies who want practical guidance on combining acceptance tests and TDD for safer refactoring and CI.

Still RelevantIntermediate

Topics