TDD for Embedded C
2016-08-10 21:33:31 UTC
Most useful learnings:
The rational behind TDD, particularly the importance of following the steps.
Make it fail first, so you know the test is doing what it's supposed to be doing.
Then when you make it work, you have more confidence that you are actually testing the right thing.
Concepts v exercises:
Presentation v discussion:
It might depend on where the attendees are located, but possibly shift the start time to try to have it run during normal working hours.
The aha moment of understanding how the Mock stuff worked in the last exercise felt really good.
I didn't really have that for the previous exercises, but I'm not really sure how you could add that kind of moment to those exercises.
He knows his stuff, and was effective at getting his point across to us.
For some code yes, but a lot of my tasks are modifying legacy code.
Challenges to applying:
Large complex system that (mostly) works.
We have a ton of so-called unit-tests, unfortunately a lot of them take a long time to run.
So the quick iterations we desire for TDD are simply not possible.
We also support a lot of different platforms, which also takes a long time to build. We have an automated build system, but it's not unheard of for it to take over an hour for some of our nightly builds.
And code that compiles just fine on my windows box may not compile on platform-X. A lot of these are probably related to all the warnings we let stagnate in our codebase.
I liked the cyber-dojo exercises, but really missed my IDE.
The remote delivery worked pretty good, with only the occasional audio dropout, but I probably could have avoided that by calling in.
But 7AM in California was a bit early for me.
Legacy code workshop:
Recommend to others: