Test-Driven Development for Embedded Software

Thank you very much, it is very useful!

Great presentation!!! I have always heard of your book as the main reference in embedded domain, and after this presentation, it's now definitely on my shopping list :)
Regarding integration/system-level tests, is it possible to create one that can validate timing constraints? I was thinking if there's some framework or recommended ways to validate in-between modules communication (which can be logical/software level only, or maybe even in-between chips), which can be critical to some systems.
Thanks in advance.

Hi James, really enjoyed your presentation and style! Right now I'm doing unit testing and debugging of code, passed by an independent developing team which is no longer available... the waterfall is right over me! wished they'd have followed TDD! Thank you very much for this introduction on the topic.

Thanks for the lecture James, your style is very entertaining. Your slide "Misconception and Sustainability" reminded me of a project in the mid 90's when the launch of our new system was delayed by 1 year because we were using TLD. After 2 years to develop the hardware, the embedded team took 6 months to test and fix their firmware. Finally the Windows team got to try their code against the system, but found numerous mismatches in the understanding of the design specification across the hardware, firmware and software teams, so the launch was delayed 1 whole year rewriting code, trying the get the thing to work. For me, TDD reduces the surprise of integration test failures like this, meaning that the launch date of the product can be more accurately forecast and the development team not face massive time pressure from the management at the end of the project. Suffice to say that the company closed 5 years later due to lost market share.

Thanks for the lecture! I like the insight of running unit tests off-target, I will try to implement it in my company. We are getting into test-driven development but we run the tests only in target, which actually takes dozen minutes to build. So I felt like test-driven development was just too slow. I believe that running off-target will help a lot!
A question - Would you say that simply mocking the platform-dependent libraries in a unit test is better than using a simulator?

Thanks for the tak.
Just wanted to add a comment, I recently started to prepare a setup for introducing unit tests on our legacy embedded codebase. To make the unit tests run on PC, I needed to compile the code using a host compiler.
An unexpected learning here was that just the action of exposing your code to another compiler, made potential bugs pop up. Different compilers complaint on different things, each enabling new insights.

Hey all you people interested in TDD. If you want to be immersed in it for a few days, consider my web delivered training. https://wingman-sw.com/training/remote-delivered-tdd
It could change your life! Your's would not be the first.

Cheers, James

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

This was brilliant

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

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.

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.

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.

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?

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

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

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...

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.

Excellent talk James!

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.

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

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.

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

Thank you Jacob

The slides are now posted! Sorry about that!

Please join the zoom meeting