Home > On-Demand Archives > Talks >

Example of BDD Style TDD For Embedded System Software

Steve Branam - Watch Now - EOC 2024 - Duration: 47:11

Example of BDD Style TDD For Embedded System Software
Steve Branam

Based on the blog post https://www.embeddedrelated.com/showarticle/1544.php and repo "Bit-Banged Async Serial Output And Disciplined Engineering" and under the aegis of Dojo Five, this session walks through a practical example of using the Behavior-Driven Development style to perform Test-Driven Development to develop an embedded system software module.

BDD adds several advantages to TDD:

  1. It results in an executable specification of a module that is understandable by both technical and non-technical stakeholders. This makes it easier to understand by all parties, and easier for them to specify additional behavior.
  2. Because of its emphasis on behavior, it guides the developer to test to interface, not internals. This minimizes the risk of creating brittle tests. That minimizes the need for test maintenance when doing production code maintenance: changing the internals doesn't create a mass of failing tests.
  3. It focuses on one aspect of behavior at a time. This ensures that tests only test one thing at a time, keeping them simple. When a test fails, it's clear what failed and what should have happened. That makes isolating and fixing the problem faster.
  4. It avoids code bloat and untested code, since every bit of production code is there because a behavioral test required it.

This additional layer of discipline makes TDD even more effective for both immediate development and long-term maintenance. It's easily applied to embedded systems modules to enable off-target testing, resulting in known-good components. It works equally as well when you start with a well-defined idea of what the module internals will be and when you only have a vague idea.

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

BobF
Score: 0 | 2 months ago | no reply

I met a cow once, boy ... was she holy !! Her behaviour towards me really tested her but ... that's another story! Great slides with lots of useful nuggets!

KeithJ
Score: 0 | 2 months ago | no reply

Hey Steve - Holy cow. There is an immense amount of useful information included there. I'm going to have to watch that 4-5 more times just to have a chance of digesting it all. :D I'm sure that took you an insane amount of time to put together. Thank you so much. Question: Would this be a decent restatement of what you're presenting or not? BDD is really a "best practices" for TDD in that you should be creating tests that describe what your code is supposed to be doing and not how? Because with TDD, you can really go off the rails with tests that focus on implementation and not function. (Reposted - see live Q&A for response).

OUR SPONSORS

OUR PARTNERS