TDD for C
2016-05-20 10:13:52 UTC
Most useful learnings:
The core TDD approach to writing new code.
Concepts v exercises:
Presentation v discussion:
On the first day - when handling the "concerns" attendees have written on the website following the initial exercise - it would be best to have a timer for yourself.
Only allow yourself to spend 1-2 minutes answering each concern, before moving on to the next.
You have them for 4.5 days - you can elaborate on point as you go (as indeed you do anyway quite well).
Legacy code exercise. This is the weakness, or so it seems, thus far for TDD.
On the face of it - there is no golden bullet (silver is not good enough). The unit testing here is conventional.
But writing tests to follow the code is not always the only acceptable option.
There is code that is not pure legacy. We have no yet tests - but there is knowledge in the team and ownership. I would myself consider re-justifying such code into existence by commenting it all out and applying TDDish incremental steps in developing steps until the code in back in. This will ensure FULL test case coverage. I'll try this a bit and see how it goes.
I got told off for following my department wiki, rather than the instructors guide, on the legacy code day. I have to like that.
I started yesterday.
Challenges to applying:
Time. It will incrementally benefit - I know. So initial speed reduction will not have an obvious payoff to project managers.
It can be more intensive.
Legacy code workshop:
Recommend to others: