TDD for Embedded C
2016-05-20 10:03:57 UTC
Most useful learnings:
I have been mostly as you said from DLP world. With that your mind condition for being bit relaxed as you somehow feel that I can debug later and correct code if needed. And that's where we miss stuff. But with this TDD approach there is little scope that you can make such mistake. Of course if haven't got requirement right things can go wrong in any approach but TDD help to refine them in time rather then parking the problem for future. So I liked this thing a lot that I know what I am writing.
Concepts v exercises:
Presentation v discussion:
So far in current format it seems fine to me. I am sure once we spent more time on our code, we might feel that something more could have been done. But that feedback can be passed later on.
If it can be more of what we do then we can connect well. Ideally if a reference code is taken from our domain and then something is shown then it would be nice.
James is a wonderful instructor. He is not mere instructor as he has done and experienced all things he taught in past so he can back what he says very nicely with lots of examples. And as he is from programmers world so he can connect well. He knows all pain areas and can address all concern nicely.
O yes. I have already started. So there is no question of tomorrow. And as we learnt that I am a programmer and I write bugs so why to wait to clean them up.
Challenges to applying:
I feel its more about culture. Major challenge is time but I feel that if we can apply it wherever possible and show some improvement, management would love to give more time in future. Other challenge is legacy code. With that somehow TDD philosophy is breaking and we are writing test after looking at code so its become development driven test!. so tend to bias test case writing and I am so far not comfortable.
Legacy code workshop:
Recommend to others: