TDD for Embedded C
2018-11-16 15:14:25 UTC
Most useful learnings:
Importance of a persistent suite of tests available as the code is developed.
Concepts v exercises:
Not enough exercises
Presentation v discussion:
I understand the importance of hands-on learning but perhaps more "group development" led by you would be more beneficial to cover more examples in same amount of time. In essence, present the task to test in small chunks, provide an opportunity for everybody to think of solutions (about 5 mins), walk through the thought process used by an experienced TDD developer with feedback from group, and implement solution live as you did. This way everyone is on same page and can worry more about learning the TDD process than a missed semicolon making the compiler unhappy or other irrelevant thing to the class. You actually did this to get each exercise started, I would recommend to focus on that with the addition of letting people think about the task for a few mins to get an opportunity to internalize the content.
Have more of them. Perhaps include tackling some legacy code techniques considering that most developers already have code that can benefit from better unit tests. Would have liked to see a TDD approach with examples to things like:
- concurrency related code
- throughput sensitive code
- how to write tests for code with large number of possible inputs cases where "none, one, many" might not apply
- Code that accesses/depends on files on host system (networked systems, sockets)
- list with examples of code that cannot be developed with TDD
I enjoyed the class, will definitely find a way to bring TDD into my development process. Pressing deadlines will surely get in the way but I will gradually bring in TDD starting with those parts of the code that are well abstracted and can have unit tests integrated quickly.
Yes, i have parts of my code that can be easily tested. Will incorporate TDD once new features are required and i am required to make changes or add new features to project.
Challenges to applying:
Schedules. If a feature is requested that can be implemented by modifying parts of the code, it is faster to do that than develop a test for the whole section containing the change. My hope is that for new features/development the time spent single-stepping or looking at printfs/logs is equal to the development of a test cases that have the added benefit of TDD.
Legacy code workshop:
Recommend to others: