TDD for Embedded C
2020-01-17 15:23:55 UTC
Most useful learnings:
I understood the "write tests first, get passing tests, and refactor" process, but I did not understand that it progresses in tiny steps. I now have a greater understanding of the iterative cycle, and how very incremental it can and should be. That part was lost on me before this class.
Concepts v exercises:
Presentation v discussion:
There were times when the instructor talked about real-life experience, and that was invaluable; however, I think the course could be improved by providing "stand-in" code to demonstrate what the overall issue was, and how code was changed to overcome the issue, instead of whiteboarding and discussing. This way, we get both the real-life experience, the why via discussion, and the how via the code changes we can visually see and understand.
I like the principle of ZOMBIES for coming up with tests, but when I was staring at the last exercise with no tests, I was a bit frozen on how to start. We switched between 3 different practice problems, and maybe it was changing between 3 completely different systems that led to my second-guessing about how to implement tests for it. Did I really understand the system, and how it should work? Did I understand how to test what I wanted but in the TDD framework? I was still thinking of tests that were too complicated and involved multiple steps. Maybe this isn't a bad thing - I can add them to my test lists, but thinking of the tiny incremental tests was my problem brought on by the newness of the entire approach. Maybe if the exercises focused on the home automation, just different parts of it?
The instructor was funny, provided real-life experience, answered questions, and presented the information and exercises well. He did go off on tangents sometimes, but they were usually informative and contributed to the overall story.
Bring it on!
Yes. We've setup test harnesses before, but were doing DLP. Many developers were manually testing and saw no point to writing separate tests. I'll push forward this methodology, so that others may finally see that writing tests can be part of the development process in a fun way as well.
Challenges to applying:
Management is very open to anything that accomplishes the job, so they are open to trying new things and learning. Developers, however, span the range of "stuck" in their ways to full on learning and grasping anything.
I liked the legacy day, and we all have our own problems to address when trying to implement this on our own projects, but maybe it would be beneficial to have a moderately complex case you provide for the morning, walk us through parts of it demonstrating some of your techniques, so we have a "how-to" we can reference in exercises. What does that mean in terms of exercises or shared code? A before and after maybe? A video showing the transition and thought processes? That's tough.
Legacy code workshop:
Recommend to others: