Course:
TDD for Embedded C++
Date entered:
2018-08-31 17:27:35 UTC
Course rating:
Good
Most useful learnings:
The idea of stubbing out features, *and then using those stubs in other features*, to pull oneself up by one's own bootstraps. I thought this was very interesting. In my own development, I tend to go "feature at a time", which means that I often over-engineer each feature. It was very interesting to see, and try, an alternative approach. I thought it did a better job leading me to implement the "minimum viable" feature to get the job done, rather than going for absolute completeness and correctness. It's kind of like the "waterfall vs. agile" problem writ small and applied to developing individual functions.
I also thought the idea of TDD'ing the test harness was very useful. I have serious trust issues with test fixtures (I've seen plenty of cases where they are buggy and testing the wrong thing...) so I like seeing them tested. Also, it's got a pleasantly fractal nature to it... if one accepts that TDD is the fastest and most efficient way of developing most code, then why NOT use it to develop test fixtures themselves? It makes a ton of sense.
Concepts v exercises:
Not enough exercises
Presentation v discussion:
Good balance
Course improvements:
More exercises!
I learn best hands-on. I am already forgetting the lectures, unfortunately. The best way to establish a new habit (like TDD) is to get a little practice using it in reality. I would have preferred the lectures to be extremely brief and sketchy (say, 15-30 minutes per day, maybe with a bit of assigned reading to make up the difference), and then dedicate the rest of the day to cyberdojo.
Exercise rating:
Very Good
Exercise improvements:
Have more exercises and allocate more of the day for them. The quality of the exercises themselves was fine.
Instructor comments:
Better prepared:
Much better
Start tomorrow:
I've already started, & intend to use TDD on the code I develop in the future.
Challenges to applying:
I don't foresee problems in TDD'ing new code. Fitting TDD-style tests to existing code may be more of a problem.
The biggest challenge is the cognitive dissonance between TDD-style tests and software-qualification style tests. TDD is not intended to verify the absolute correctness of the code, but to behaviorally test it in a way that makes the code easier to develop, refactor and maintain. When we say "this code has tests", we will now need to be very careful to clarify what style of test we are talking about.
Other comments:
More exercises!
Legacy code workshop:
Yes
Recommend to others:
Only if improved
Quote permission:
No