Key Topics
- [02:30] Definition of BDD as an additional layer of discipline on top of TDD
- [03:15] Common pitfalls of TDD, including testing to implementation and brittle tests
- [08:30] The structure of BDD tests using Given-When-Then format
- [12:00] Applying BDD at different levels, from unit tests to system tests
- [15:45] Using test doubles and spies for hardware interactions in embedded systems
- [22:30] Testing state machines with BDD
- [27:00] Off-target testing and hardware abstraction layers
- [33:00] Why BDD isn't more widely used in embedded systems
- [36:30] Using code coverage as a signal rather than a goal metric
- [39:00] Overcoming the learning curve and maintaining discipline in BDD
Notable Quotes
"BDD is an additional layer of discipline on top of TDD. Dan North's goal was to get straight to the good stuff of TDD without getting into the pitfalls." — Steve
"The key thing that BDD does by saying we're going to focus on behavior is you look at the API that you've written and you say, what can I do through the public API to affect this, to check the results and so forth?" — Steve
"By having abstraction layers, you create your thin layer that's substitutable with either the real code on target, or with a test double off target." — Steve
"Code coverage as a goal metric is not a good thing. Rather than using code coverage as just this almost dimensionless metric, use it as a signal to guide you." — Steve
"By adhering very strictly to the simple rules of how to do BDD, by forcing yourself to the discipline of that strict adherence, it keeps you on track." — Steve
Resources Mentioned
You can find Jeff at https://jeffgable.com.
You can find Luca at https://luca.engineer.
Want to join the agile Embedded Slack? Click here