TDD for Embedded C
2016-10-26 19:07:29 UTC
Most useful learnings:
Assumption it is cheap faster easier to fix bug earlier in the process than later.
The best value is to discover real bugs as early in the process as possible.
Concepts v exercises:
Presentation v discussion:
TDD is not a cure all for bad practice. Touched on in final discussion. Some coding is just plain bad practice. TDD is not a Panacea against it. Cyclomatic complexity, LOC in a routine and so on.
There needs to be an up front expectation of reasonable coding practice.
TDD is a tool in the box not a cure all.
For example - the real constraint at Panasonic is - people do not understand what is required.
Assumptions are made - that may be wrong. Real understanding does not arrive until customer objects.
Also there are some inherently automotive challenges - Initialization and shutdown. THese deal with runtime behavior and system level behavior.
To me TDD is make sure what I 'know' I want to do, I actually do.
What I want is to do this part right, then understand analogous step to transition to integration test - with a methodology similar to TDD. and scale up from there.
They are good.
Challenges to applying:
Value add. jump into the nuts and bolts faster. People already get the need for it.
Legacy code workshop:
Recommend to others: