TDD for Embedded C
2016-02-23 08:09:07 UTC
Most useful learnings:
The usefulness of having comprehensive tests and needing to refactor code
Concepts v exercises:
Presentation v discussion:
Maybe the ability to store/zip the code dojo code we wrote for future reference.
Maybe a bit more on module test after the unit tests have been created.
Possibly and example of the completed version of the exercise to ensure people were on the "right path"
James was good a good instructor and did well at monitoring peoples progress.
With such a big group it is hard to keep up with everyone, but maybe pointing out some more classic mistakes would have been useful in changing out mindset to TDD.
Yes but a lot of my code it knitted in with others so it isn't easy to just wrap a function and being testing.
I have started putting in the framework for one of my modules, so I haven't given up.
Challenges to applying:
Being end date driven means we already drop design to have enough time to implement.
Poor requirements means that creating tests is harder, they do not tend to firm up so assumptions are made.
Not being able to phase functionality very well, functionality is normally in quite large chunks, we need to try and phase it better so that even if it takes longer there is always partial working functionality.
Even though peer programming is a wonderful idea and everyone agrees it would be great, we are stretched to the limit already so doing this would affect our initial revenue (but probably cause less bugs long term)
Days 1 and 2 were good balance between exercises and talking, day 3 was very wordy and was a bit of a slog. I don't know if it's possible but maybe move some more of the exercises into day 3 to break it up a little better?
Legacy code workshop:
Recommend to others: