TDD for Embedded C
2021-05-27 18:52:02 UTC
Most useful learnings:
I learned the value of taking small steps, "cheating" with the most basic implementation, and in always making it fail first. When I read your book these techniques were something that I wrote off as being the "ideal case" that nobody would ever do in practice, but after using it in the exercises it finally clicked for me just how useful these techniques are. This is not an example of perfectionism, but it is the heart of the whole process.
I have a tendency to over-analyze and over-design things from the start, so I usually have a basic draft implementation before I write tests. This has always forced me to climb out of a fairly large hole when I begin to add unit tests, because I have a lot of code to cover after the fact. I thought that skipping the small steps would save me time, but it is clear now that the exact opposite is true.
Concepts v exercises:
Presentation v discussion:
I noticed some duplication between concepts you were covering during the session and concepts that you covered in the recommended homework videos. Since we have such a limited time in the class it would be better to not go over the same material twice (probably easier said than done with so much material). I did watch the "extra credit" videos, so maybe this is to be expected.
It might also make sense to use some kind of "discussed" tag for the parking lot issues so we don't cover the same concerns more than once.
I would definitely use Gather Town in the future. It worked very well even using the basic setup, so I imagine it could be even better with some customization. I wonder if pair programming during the exercises might have helped avoid some of the "I don't know what to do" scenarios. It might also help to have participants do some gather town training as part of the pre-course preparation homework.
Pairing up (using Gather Town) would maybe be helpful so we can bounce ideas off of each other or help each other understand things better.
A shortcut key list for the dojo would be helpful.
It would be nice to be able to expand the coding dojo window a little bit more. Supporting one split window would help a lot so we can view the code and the test files at the same time. It may be more complexity than it is worth, though, especially to avoid confusion.
It would also be helpful to have code completion support in the coding dojo. I noticed that I spent a good chunk of time jumping between files to get function/enum names, and many test cycles were just me fixing typos. A good auto-complete would make it easier to keep focused on learning and experiencing the TDD process instead of switching between files to get the right type/function name.
As a Vim user I was sometimes distracted by these minor environment weaknesses, but I know you can't please everyone.
James was a great instructor. It is obvious that he knows what he is talking about and that he's done this before, and that he has seen most of the complaints/questions countless times. I was impressed by the breadth and depth of his knowledge on the different testing frameworks and languages. He not only knows his stuff, but more importantly he also knows how to teach it.
Yes, I plan on starting to familiarize myself with the CPPUtest framework with the goal of running through your "legacy code" process. That was the most significant challenge when I first tried to apply TDD to my work, and I finally feel equipped to handle the challenge. That helper tool you demoed today was awesome. The process and your tool look to be priceless (as someone who has banged his head against the toolchain while trying (and failing) to tackle this problem before).
I think this course has helped fill in most of the little gaps in my knowledge/understanding of TDD, which is exactly what I was hoping would happen when I signed up.
Challenges to applying:
It will be most challenging to take the time necessary to get our legacy code in the testing framework. Adopting TDD for greenfield projects or library development will be much easier.
It will also be challenging (as always) to convince coworkers of the value in unit testing (let alone TDD). I feel much more equipped to "sell" the process than I was before the course, though.
I imagine this will require me to do all of the heavy lifting of getting our code in tests, so that it is easier for others to just add tests without the large initial barrier of setting up the toolchain. I had this problem before when trying to get people to adopt Ceedling (it depends on Ruby, uses a special YAML file for build configuration, and does some magical code generation that can be confusing to set up). One advantage I see in CPPUtest is that it relies only on C or C++ code, which my colleagues stand a better chance of understanding without additional studying.
I thought the remote delivery was very effective. It might have been better to know about how long I would need to complete the homework exercises so that I could more effectively plan my time around work, but other than that it was great.
I thought Gather Town worked perfectly, and it is exciting to think about how it might be used in the future for things like this. The "natural" interface of moving your character through rooms and using distance-based sound drop-off was very easy to adapt to. I can't imagine it would be nearly so easy to do the same thing in Zoom/Teams/etc.
Legacy code workshop:
Recommend to others: