Course:
TDD for Embedded C
Date entered:
2020-07-31 03:45:41 UTC
Course rating:
Very Good
Most useful learnings:
That there isn't anything novel, hard, or expensive (like simulators, emulators, etc.) that has to be done to "do" TDD for embedded - that I can use proven software engineering concepts - TDD and programming to interfaces (i.e., test doubles) - to achieve off-target testing (with caveats - more in other feedback comments).
Concepts v exercises:
Too many exercises
Presentation v discussion:
Good balance
Course improvements:
I'd like to see more focus on the concepts (why I chose "Too many exercises"; really meant "not enough concepts"), since I came away not knowing the difference between "fakes" and "doubles". Sure, that's what Google's for, but why be in a class with homework for three days and still not be clear? I can't explain to someone the difference or know which one to use in which situation. I found an article from Uncle Bob, which I'll read so maybe not a huge deal, but you could improve the class by adding a bit more clarity by more clearly defining the test doubles and when to use them.
Also, sometimes concepts from class and/or homework felt a bit scattered and/or without context, even if they are good to teach professional software engineers (e.g., code smells is good to know about, but kind of tacked on at the end).
Exercise rating:
Good
Exercise improvements:
The exercise topics were good, but I did run into a couple issues days 1 and 2 that weren't pertinent to learning the concepts of the course and that was frustrating. Maybe it was just me, but a couple hints on macros for those less-experienced could help people like me.
On day 1, after you demoed the initial tests to us (and which I completely followed), I was under the (false) impression that those tests were already being provided to us and we would pick up from there, so I removed those sections. I eventually recovered after some time, but then missed the point of the "pair programming" concept (i.e., macro to comment-out undeveloped tests).
On day 2, the 1st part of the exercises went without a hitch, but I got syntax errors doing the refactorings as instructed to make the multiline macros.
Instructor comments:
Better prepared:
Moderately
Start tomorrow:
I can apply concepts like making lightweight lists of test ideas from a "specification" (e.g., requirements doc, code, etc.) - I did that yesterday vs. normally designing "all" the tests up front, so being more agile! I can also start using the test doubles concepts (even if I don't know the difference between 'spy' vs. 'fake' yet).
I don't know about true TDD for embedded, though. Still need to use our custom test harness where a build and deploy to the HW takes ~60-90 sec. I can make my tests fail before I fix or create code - step in the right direction and improvement. But I'm not sure how we can create completely off-target unit tests the TDD way, eventually deploy new code to the target, and have a way to unit test that code on the target, if the unit tests were just "regular" unit tests (vs. in our custom harness). Not sure how the unit tests would talk to the target at that point. Can't just run them on it, either.
Challenges to applying:
Both technical (see above) and cultural (getting the smaller (embedded) and larger (project) team onboard). I've been a big proponent of TDD for years (on other projects) and my current project has been experiencing great success being agile and using Scrum, but one of the few technical processes associated with those frameworks that they never mention or use is TDD.
Other comments:
I would have liked to hear some more discussions/Q&A - but I'm an introvert, so I realize that being remote, that can make it easier or harder, depending on the day ;]
Legacy code workshop:
No
Recommend to others:
Yes
Quote permission:
No