Course:
TDD for Embedded C
Date entered:
2017-02-22 21:33:02 UTC
Course rating:
Good
Most useful learnings:
TDD at its best is a quick, tight loop of [modify, test -> fail, modify, test -> succeed ]
Concepts v exercises:
Good balance
Presentation v discussion:
Good balance
Course improvements:
I feel I missed out on any experience of TDD in the later stages of development. Obviously you can't throw a complicated and extensive implementation at a workshop and have trainees feel that they are making any progress within the first hour or two. But you could *demonstrate* later state development with an implementation you are familiar with. In particular, I would have liked to see dealing with issues like these: Reworking the external interface of an implementation. Completion of test (ie when have I tested enough). Maintenance (ie version 2.0).
Exercise rating:
Very Good
Exercise improvements:
Skip ahead in the process to a step with a more complete implementation. (Maybe a few of the participants made it far into the implementation, but I think those following the rules of TDD "don't write code until you have a test for it" and "add one test at a time" would not.) Eg have the circular buffer complete up to a point like "works until you add when it is full" and start TDD from there. Or, works perfectly, now make it so it resizes larger automatically up to some size.
Instructor comments:
Excellent. Well prepared. Sometimes I think you brushed off my concerns without really understanding them (and certainly not discussing them) because they weren't on your agenda.
Better prepared:
Bring it on!
Start tomorrow:
Sure. I would absolutely try this immediate on a new design that I feel is suitable. I'm still not convinced that it is worth wrapping some designs in test, and these are ones I'm working one. In particular, designs where you don't know the required behavior until you actually do system test, and/or designs where the complexity of the external interface is large compared with the actual code implementation. (These are probably the same as cases where the size of the test code--used and obsolete--is orders of magnitude larger than the release code.)
Challenges to applying:
See above. Lots of legacy code with complicated interfaces. Many cases where, yes, the legacy code is the spec, but I already know it is bad and I'm throwing out the spec--particularly when the code I'm replacing is much more complicated than what I'm replacing it with. I'm also deeply concerned that there will be a false sense of accomplishment: the most costly problems I see in bad designs are poor factoring and designs that only solve part of the problem--at the system level. TDD will probably influence bad programmers to do better factoring, but in general is not going to fix these problems. And after you have a large and powerful test wrapped around components of a bad design, will people have the guts to throw it all out, as they should?
Other comments:
I'm glad it wasn't started earlier in the morning.
Legacy code workshop:
No
Recommend to others:
Yes
Quote permission:
Yes