Course:
TDD for Embedded C++
Date entered:
2018-08-31 22:15:48 UTC
Course rating:
Good
Most useful learnings:
Tests should be written to provide the bare-minimum implementation support necessary for the test to proceed. Prior guidance/requirement was to explicitly walk the implementation through its code paths. Tests are much more scalable/efficient if the test is loosely coupled to the implementation and bring down the obstacle of "I can't change the implementation because updating the tests is too expensive".
Concepts v exercises:
Not enough exercises
Presentation v discussion:
Too much presentation
Course improvements:
I think the course would be more useful if the presentation focused on driving home the unfamiliar concepts that make TDD beneficial and then use more small group exercises with roaming guidance to ensure the small groups are using TDD practices in effective ways.
Exercise rating:
Fair
Exercise improvements:
I enjoyed working with current code base rather than the provided examples. The examples are a bit too contrived. They also provide a lightweight design (UML diagrams etc.) but I don't feel enough emphasis was placed on doing some preparation before jumping straight into TDD. When we tried to do TDD without some lightweight design work upfront, we ended up with an architectural nightmare- as implementators didn't see any reason to coordinate about cross-cutting concerns.
Instructor comments:
Better prepared:
Bring it on!
Start tomorrow:
Rather than concentrate on the "you" I believe the better question is "can you and your peers start tomorrow?" I believe we are closer to getting to that starting line, but its going to take awhile for the old habits/fondness of current tests to wear off before everyone truly invests in testing.
Challenges to applying:
There is too much groupthink- where a small group of common thinkers come up with a solution and insulate that solution against outside criticism.
Other comments:
In general I'm uncomfortable with promoting TDD as a design methodology. While TDD certainly helps aid in design, I don't think the presentation put enough emphasis on doing a minimal amount of upfront design before jumping into TDD.
For safety critical, its often possible to architecturally mitigate cross-cutting concerns that would otherwise require increased complexity in the implementation. Perhaps a well established TDD culture would identify this early, but our current culture often misses this opportunity for greater coordination.
Legacy code workshop:
Yes
Recommend to others:
Only if improved
Quote permission:
Yes