TDD for Embedded C
2023-10-26 20:37:09 UTC
Most useful learnings:
TDD helps us reducing bugs by driving the implementation I am testing. This has genuinely surprised me to see the implementation evolved from a "stupid" hardcoded return value, to the actual action I wanted the code to do.
If I had to pick one, and because it is funny, I'll do for the ZOMBIES. Although I was skeptical at the beginning of testing "nothing" (the zero case). It sounds counter intuitive to test that at creation nothing happens. Well, this was before really driving the implementation by the tests. And start growing the tests, and then the implementation, with just what we need.
Concepts v exercises:
Presentation v discussion:
I think there was enough exercises. It is challenging in 4 hours to have interaction with James, doing exercises, presentation, reviews, so this was a great balance IMO.
The gather tower is a really fun way to interact to each other. The dojo site provides a ready to use exercises so we do not need to bother to setup the environment, and let us focus on the concept of TDD. Excellent.
Having the book is a must have in my opinion, as it has all the concepts explained in the sessions, but even more. Participating to the class could provide a discount to the attendees.
The dojo website makes us focusing on the TDD aspect of it, awesome. I wish there were a more collaborative view embedded in dojo, where I could see the cursor of my peer and we could interact together simultaneously, but thanks to the app gather that was not a need anymore. All the exercises were well guided and concrete.
I would have liked to have a better continuity to the exercises: we started with a simple example without dependencies; then a more real life example with dependencies. Yet, I think it would have helped me to have the CircularBuffer in use in the LightScheduler. Given the "octopus" of collaborators mentioned by james, the buffer would be at the very bottom, and the LightScheduler some layers above. But I am not sure now, since I have tests for my circular buffer, how is this impacting my tests for the light scheduler. Does it even matter? That is something I'd have liked to explore.
James is awesome, I could feel is experienced, he is humbled. We did have minor presentation issues, but that's what presentation is, isn't it?
I loved the time spent during the sessions, James knows what he talks about, have plenty of stories to be told, and is very clear on the intent of the class.
The videos are funny!
I'll start right away! Although my very first application won't be TDD as I have to create the unit tests for a recent legacy code that has been created, so the last session about the legacy code was definitely helpful.
Challenges to applying:
Applying the concept of TDD given the time pressure for deliveries.
But we have a really good testing culture at my companies, but only for Hardware in the loop, which tends to be really expensive, time consuming, complex, and does not help much to find the bug early.
We do have unit testing, but not every devs do testing, so why not spreading that cultures.
The remote delivery works really good! THe attendee interface is simple enough to not get lost.
I honestly would I have liked another day, or a 1 or 2 more per sessions, to cover more of the test-double re-usability, a bit more emphasis on the design patterns (dependency injection, SOLID principles, James mentioned often the adapter, etc..).
Legacy code workshop:
Recommend to others: