Home > Tracks > Embedded Systems Programming

Test-Driven Development for Embedded Software

James Grenning - Watch Now - Currently watching: 0

You've heard about Test-Driven Development but have never tried it or don't quite get it. Test-Driven Development is an important design and problem solving technique that helps software developers improve product quality and the quality of their life. How? By preventing defects, protecting your code from unintended consequences, and giving you warning when your design starts to deteriorate.

In this presentation James describes the problems addressed by TDD. He will define TDD and show you a short example of TDD. He'll tell you some of the benefits you can expect from TDD as well as the challenges of applying TDD to embedded C and C++.

James Grenning is inviting you to a scheduled Zoom meeting.

Topic: TDD for Embedded Happy Hour Embedded Online Conference
Time: May 20, 2020 03:00 PM Eastern Time (US and Canada)
Every day, 2 occurrence(s)
May 20, 2020 03:00 PM
May 21, 2020 03:00 PM
Please download and import the following iCalendar (.ics) files to your calendar system.
Daily: https://us02web.zoom.us/meeting/tZYpce2ppjMrEtMuPJuyVD1AFYDeKiBVi3vc/ics?icsToken=98tyKuGqqj0uG9ydsRGARpwQBo_oLOvxiFxcj7dwiS_PFjllRlLXENtmN5l2Mu7Z

Join Zoom Meeting

Meeting ID: 824 6418 8187
Password: 031453
One tap mobile
+13017158592,,82464188187#,,1#,031453# US (Germantown)
+13126266799,,82464188187#,,1#,031453# US (Chicago)

Dial by your location
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
Meeting ID: 824 6418 8187
Password: 031453
Find your local number: https://us02web.zoom.us/u/kflJGFuSy

italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 2 days ago | 1 reply

Hi. Thanks for great presentation.
What are your opinions if you are developing something new. I mean, the thing is you have never done, the thing you researched and decided to develop, the thing that doesn't have been experienced by you before.
Since in that kind of work everything has possibility to be thougt incorrectly, to be done in another or more efficient way etc, making TDD tests along with code might double your work before you rewrite everything (which is very possible). Do you suggest TDD even for that situations? What do you suggest

Score: 0 | 1 day ago | no reply yet

Hi Yunus
I have a presentation about your question, recorded at Agile 2019 called "Deep Stack – Tracer Bullets from ADC to Browser". Here's the link:


It's about a green field product I was working on and how and where TDD fit in. The short answer is that while I am discovering how the system works, I don't write tests for the code at the boundary of the unknowns (like HW, or some external API). But I am testing my understanding though little prototypes and experiments. Once my understanding solidifies, I can test drive where it helps. Which is most the code if you design for test.

Score: 0 | 2 days ago | no reply yet

This was brilliant

Score: 0 | 2 days ago | no reply yet

Excellent! Very impressed with the style of the presentation and the message. Thanks!

Score: 0 | 5 days ago | 1 reply

This was a very great helpful talk, thank you James,
i enjoy the way you apply the TDD on Embedded systems, in the beginning i though TDD is not for Embedded Systems but now i believe it will help a lot.
Can we apply the same to a High Safety Critical Applications? were we almost write all the Block Diagrams, functions, interfaces,... as Pseudo Code(or higher level language) then test it then Coding is the last thing to do.

Score: 0 | 4 days ago | no reply yet

Hi Mina
I don't see why you would not be able to use TDD for safety critical. TDD is really about being careful, and making sure your code does what you think it is doing. You could start without changing your design process, and then grow the modules you specify in diagrams with TDD. You will probably evolve your design process as you grow your skills in TDD and see how some of the earlier design ideas were prematurely decided.

Let me ask, when you finally get to coding in your process, do you change and evolve the design ideas as the reality of code becomes evident? The test-driven approach is realistic in that it assume that we will change design ideas (and system needs) as we get into solving system design problems.

If you want to talk further, contact me. https://wingman-sw.com/contact-us

Score: 0 | 5 days ago | 1 reply

James! Great stuff. I just thought I would say debug statements in context of logging is not necessarily an exact swap with test driven code. Often times Logging is important for multithreaded code, reporting calculated values, or to provide a tool for a non-sw engineers to do first pass debug through your application (say a service organization). In other words, sometimes logging (which sadly some people use entirely as their debug method) actually enables other people with a tool to inspect behavior.

Score: 0 | 5 days ago | 1 reply

Hi Foz

The TDD concern I was addressing, that I hear basically from every group I teach TDD, is that TDD means there are too many lines of code to maintain.

My comments about comparing LOC for test and LOC for debug is in part to get people thinking about the alternative and how they currently do not even notice the amount of code dedicated to debugging. I am not saying logging is not needed. Application/product usage logging is very valuable. The logging you mention is not what I am talking about.
I want people to self-reflect on their work and code.

I hope this statement gets people thinking:

People object to code added proactively to prevent defects, but accept without concern all the debug statements added to code reactively to respond to defects.

Thanks for the comment!

Score: 0 | 4 days ago | 1 reply

"People object to code added proactively to prevent defects, but accept without concern all the debug statements added to code reactively to respond to defects."

Yeah I like that. Thanks for your hard work! I used to teach at CU Boulder ECE, I just submitted your book to their curriculum as the foundation for embedded test and debug in their curriculum reform.

Score: 0 | 4 days ago | no reply yet

Thanks Foz!

Score: 0 | 6 days ago | 1 reply

I enjoyed reading the book thanks. It was the first time I’ve heard about TDD in the context of embedded software. I first used it on a C# web app and it was a real eye opener.

Score: 0 | 4 days ago | no reply yet

Thanks for the comment.

Score: 0 | 5 days ago | 1 reply

Great presentation and explanation of TDD.
The TDD "microcycle" seems to encourage incremental coding, at the lowest level to solve the current test case. Do you find that the higher level design view gets lost and that developers implement diverging approaches, for example one interface copies data while another interface passes pointers. Do you have strategies to prevent that?

Score: 0 | 5 days ago | no reply yet

Hi RayS
I encourage developers to have a vision of where they are going. Kent Beck, the creator of Extreme Programming and TDD calls it a system metaphor. I find the term architectural vision to be helpful. Call it high level design if you like.

Also I encourage collaborative work, including

  • common language around communicating about code problems (Fowlers code smells)
  • common language about design (Robert Martin's SOLID for starters)
  • agreed coding standard
  • collaboration in real time with pair programming, mob programming or very frequent reviews
Score: 0 | 6 days ago | 1 reply

Good stuff James! Really enjoyed your book, although might need to read it again to refresh my memory :)

Score: 0 | 6 days ago | no reply yet


Score: 0 | 6 days ago | 1 reply

Excellent Book and methodology. Once there never look back (almost...)

Score: 0 | 6 days ago | no reply yet


Score: 1 | 6 days ago | 1 reply

One aspect of TDD that I enjoy the most (and it should be emphasized more!) is the sheer fun of programming that way. It's becoming like an addictive game. You make progress! You actually exercise your code. Contrast this with DLP (Debug-Later Programming). It's getting boring very quickly. You lose interest...

Score: 0 | 6 days ago | no reply yet

HI Miro
Thanks for reminding me of this essential part of TDD that makes it sustainable

TDD is Fun!

I stress to people new to TDD that this value proposition:

What if you could do more of what you like and less of what you don't like?

TDD is Fun, saves time and money. Who's not up for that?

It does take some time to learn.

Score: 2 | 6 days ago | 1 reply

Great presentation. I'm early in my TDD career, but I am starting to get the hang of it. I recently had the chance to do a SW review where we added a feature to some 'high value' technology for our business that is super hard to test. In that review I showed the final integration test of the feature in Cpputest before we transitioned to HW testing. It was an eye opener for several folks at our company to see the technology running outside of its hardware in a test rig.

Oh, that is a great assortment of T-shirts.

Score: 0 | 6 days ago | no reply yet

Thanks Pete. I'd love to hear more about your story. I collect Stories from the Field on my website and invite you to write one!

Score: 1 | 6 days ago | 1 reply

Excellent talk James!

Score: 0 | 6 days ago | no reply yet

Thanks Jeremy.

Score: 2 | 6 days ago | 1 reply

Thanks for producing the most entertaining video of the whole conference. I appreciate the extra time and effort you put it to jazz up the presentation. Your example of delivering the cracked cup holding by a string, is a really nice metaphor. I am a fan of TDD, being on the validation side, and promote it when I have the chance. But I am consistently placed under the roaring, uncontrolled waterfall. For embedded systems, in which various subsystems are from different years, it is admittedly difficult to get a consensus for TDD. Getting all the timings right, and the functionalities right, every time, with limited development and test time, and resources, remains a challenge.

Score: 0 | 6 days ago | no reply yet

Thanks Jean! Hopefully TDD can help you out from under the waterfall!

Score: 0 | 6 days ago | 1 reply

I upvoted JeanGoulet's comment. What an amazing level of effort. Thank you very much!

Score: 0 | 6 days ago | no reply yet

Thanks Matthew

Score: 0 | 6 days ago | 1 reply

very nice presentation. Very similar to what I am teaching myself to learners of Quebec,Canada. An pros to using TDD that I would have liked to hear more is the fact that this technique drives the project's functions to be easier to use. Since you write the test first, you decide here and now how is the easiest way to call a specific function or to obtain a specific behavior. You then have the hard task of dealing with this "ease of use" requirement inside said function. DLP programmers tend instead to code functions the easiest way they find, leading into complex calls, parameters hard to provide, etc.

Score: 0 | 6 days ago | no reply yet

I totally agree. There is a big focus on interface in TDD. My article, TDD Guided by ZOMBIES , reinforces that idea.
Thanks for the comment.

Score: 0 | 6 days ago | 1 reply

Excellent talk. Question - can unit tests be used for legacy code, i'e added later. How does affect the process

Score: 0 | 6 days ago | no reply yet

The test-drive developer approaches legacy code carefully. They understand their vulnerabilities. Code is easy to break and hard to keep working. We follow the principle:

It's easier to keep a system working than to fix it after you break it.

In the context of changing legacy code, you'll do many of the things you currently do, like dig through the code to try to understand the code. Before changing code, we'll usually bring the file, ideally untouched, into a unit test harness. (sometime some minor organizations changes are made, not logic changes).
Say you are fixing a bug and you suspect a particular function...

  • Call the function from a test case
  • Write a test to reveal the bug
  • Write some more tests, as bugs nest together and you do not want any unintended side effects. Also the tests help you confirm your understanding.
  • Fix the bug.
  • Do some improvement to the code, now that you have it under test.
    Here is an article on the topic TDD How-to: Get your Legacy C Into a Test Harness
Score: 0 | 6 days ago | no reply yet

Thank you Jacob

Score: 3 | 6 days ago | no reply yet

The slides are now posted! Sorry about that!

Score: 0 | 6 days ago | no reply yet

Please join the zoom meeting