TDD for Embedded C++
2018-08-31 22:15:48 UTC
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
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.
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.
Bring it on!
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.
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:
Recommend to others:
Only if improved