Test-Driven Development for Embedded C
Fearless Embedded Developement
See the Wingman Software - Self-Paced Learning home page, to read about our mission and view other courses.
This course is designed to help you, an embedded developer, change your life. I bumped into Test-Driven Development in 1999. I spent the previous twenty years professionally developing, managing, and consulting on embedded systems development. Without TDD, we often worked in a fog of uncertainty which brought fear with each change.
Our main focus is embedded systems development written in C and C++. While our examples are geared toward embedded systems, the techniques can be used by any developers working in C and C++. You'll be able to apply the knowledge an skill gained from our courses in whatever language and environment you find yourself in.
We’ve all done it—written a bunch of code and then toiled to make it work. Build it and then fix it. Testing was something we did after the code was "done". Testing was an afterthought, but it was the only way we knew. Is coding followed by debugging the only way?
The Risk of Debug-Later Programming
A mistake lays hidden and becomes a bug only once it is discovered. How long does it take to discover the cause of the bug? That is an unanswerable question! When did the code get written? Did you write it? These all impact the find time. The fix might be easy. But if the bug has been there a while, the fix will likely break other code that depends on the bug being there.
If that is not bad enough, the bugs often show themselves at the worst possible time. The most important reason for the release may be delayed by a bug surprise attack.
The Potential of Test-Driven Deveopment
In Test-Driven Development, the developer works in a feedback loop where mistakes are put in your face! Write a test, watch it fail. Add the code to make it pass. If you make a mistake, it's as easy to find as it ever will be. It's in the code you just wrote. Test-Driven Development won't prevent all defects, but it will prevent a whole class of them.
What would you rather do: chase bugs or prevent them? Being proactive and preventing defects is your choice.
Test-Driven Development Benefits
+ For all developersPreventing defects is the obvious starter benefit of TDD... Is that all there is? No! There are other benefits. In this course you see that TDD can help you:
- Provide a safety-net for future changes.
- Support evolving features.
- Support evolving design.
- Create a more modular and loosely coupled design.
- Create an executable specification of your code.
- Earn confidence in your code.
- Spend fewer nights and weekends in the lab.
Embedded development has its own special problems. Nicely, TDD can help you make more progress and manage some of these special problems. TDD and off-target testing can open the target hardware bottleneck.
- Making meaningful progress before hardware.
- Using powerful standard development tools.
- Growing code that is platform independent.
- Reproducing software problems off-target.
- Isolating hardware/software problems.
All that and TDD is fun!
The fact that TDD solves real problems and is fun, makes it sustainable.
What you get with this course.
- Self-paced course.
- In-depth requiring 3-4 days to complete.
- Numerous video presentations.
- Coding demo videos.
- Hands-on programming exercises.
- Solution demos.
- Exercise debriefs.
- Source code for exercises and solutions.
- A 25% discount code for James' book Test-Driven Development for Embedded C
See what experienced developers have to say about TDD
+ Tweets from experienced Test-Driven Developers, on TDDI asked on twitter
- How long have you been practicing TDD?
- What do you like about TDD?
- What was your first impression?
See how experienced test-driven developers answered those questions.
Here are stories from prior training attendees. They tell how Test-Driven Development changed their work lives.
+ I finished two months early!My doubts that TDD could be used for an embedded application with an emphasis on external peripherals have been eliminated, and I have found the time invested in writing tests and mocks to be well worth it.
- I required only 4 days of actual hardware testing before achieving my integration goal and that goal came essentially 2 months ahead of schedule.
- For the past 5 months, since May, I have not used the in-system Debugger at all and instead rely on TDD to minimize the introduction of bugs in the first place.
Based on my experience, I found TDD to be a positive feedback exercise – passing my first tests & catching bugs immediately, encouraged me to write more tests, which lead to more successful results until I now have a high level of code coverage and a handy set of regression tests. (And since I wasn’t frantically debugging in the lab, I had enough time to write this article!)
Thanks, Name Withheld
Read the full story.
+ I was skeptical.
Gareth Pennington Software Engineer Logitech, Inc.
+ Our code got smaller and keeps improving!
From Test Driven Development Is The Only Way To Go
-- by Ben Widsten
NCR, Embedded Systems Firmware Developer
linkedin.com/in/ben-widsten-1089656
Our firmware team develops embedded software for Automated Teller Machines written in C. Our team was first introduced to Test Driven Development in May 2014 when James came to our office for his one week TDD course. The concepts were very strange and foreign and quite often he suggested we should do things exactly opposite as we were. Towards the end of the course though, it began to click. As soon as we got back to work after the training, our code started to get better – slowly but surely. Most of our existing code wasn't testable in its original state. But with the new knowledge of what testable code looks like, we started making incremental improvements towards testability while doing bug fixes and adding small features. Eventually, we started adding new features to legacy code (code without tests) using TDD.
...We’ve been practicing TDD for a few years now and have reached the point where all new code is developed using TDD. Our code is continuously improving but at the same time, the team’s approach to software development is improving too. ...
TDD has not been without it's learning curve. ... We can respond faster and more confidently to bug fixes and requirements changes. We have shown that fewer defects reach our test lab reducing the number of manual test iterations and ultimately, fewer defects reach our customers.
Read the full story.
+ An order of magnitude fewer bugs.
From How's your testing culture?
-- by Ryan Hartlage
Lead Frameworks Architect at GE Appliances
linkedin.com/in/ryan-hartlage-a43a5686
My first real exposure to TDD came during a project that slowly spiraled into development hell...
... My single biggest takeaway from James’ training was that we were going to need to design and build software much differently if we wanted to take advantage of test-driven development. ...
... TDD was critical in helping us to overcome this challenge because it allowed us to define and measure success in the abstract. This really hit home for us when we were able to get a new networking stack that we developed entirely on a PC with TDD up and running on target hardware within hours. To date, we have never had more than a single open bug in this stack, and the total number of bugs identified is in the single digits. Learning test-driven development was a tremendous amount of work for us, but even the early results justified the investment. ...
... We’re now almost 5 years into our TDD journey and have recreated our team and team culture around the lessons we learned while learning and practicing test-driven development. ... We now have nearly an order of magnitude fewer bugs escape our team... I contend that adopting TDD and thoughtfully applying the lessons learned while doing so have helped my team to make 10 years of progress in less than 5.
Developing without tests and “cowboy” coding are unfortunate realities within much of the embedded industry, but I am not willing to go back to working in that sort of environment. I have a shortlist of questions that I always ask prospective employers and “How's your testing culture? Do you develop using TDD?” is at the top.
Read the full story.
+ Finding, Fixing, and Testing a Firmware Bug Without Hardware.
From A Case Study on Finding, Fixing, and Testing a Firmware Bug Without Hardware
-- by Phillip Johnston -- embeddedartistry.com
Read the whole story.
+ I Should Stop Making Excuses About Unit Testing Embedded Code .
From A Case Study on Finding, Fixing, and Testing a Firmware Bug Without Hardware
-- by Phillip Johnston --
embeddedartistry.com
Read the whole story.
+ Career Changing.
From Career Changing
-- by David Cozens --
Read the whole story.
+ A Mistake Used to Take Weeks of Manual Retest.
From Using TDD for legacy code in a sandbox
-- by Thomas Van Sistine -- linked in
Principal Engineer at A.O. Smith
This particular story is about applying TDD to a legacy product for a new feature particularly difficult to simulate. The application is a commercial water heater that we wanted to adjust a parameter based on heater duty cycle, i.e. heating on time to off time. Heating cycles may vary from a few minutes to many 10s of minutes. To further complicate the matter we don’t want to react to just the last duty cycle but notice a trend over many duty cycles to categorize it to three possible states; low, medium, or normal.
We have bench fixtures with knobs and switches we use for simulating a water heater operation. To test the new feature would mean hours of testing and timing to ensure duty cycles were calculated correctly and to verify the proper decision as to the duty cycle state is made.
Unless I wrote flawless code the first time, repeating the tests each time a mistake was found could have meant weeks of development and test time.
Read the whole story.
+ Memory Leak Plugged!
From Off-Target Testing And TDD For Embedded Systems
-- by Steve Branam -- blog
This was a case of a very slow memory leak, that only manifested with lots of table changes. In a customer environment, it could take a long time to chew through memory. In the lab running on-target, it was even slower, since we didn't know what the cause was, so we didn't know how to trigger and reproduce it.
Off-target, it took less than an hour to find. Code change: add two lines to free the pointer nodes. This was after many man-weeks of effort for all the people involved in trying to reproduce and chase down the problem, plus all the aggravation caused at customer sites. Ten minutes to code, build and verify the fix.
Read the whole story.
+ "it's so easy to make an innocent mistake"
From Embedded TDD: Freeing us from the Target HW Bottleneck
-- by Phillip Johnston -- >embeddedartistry.com
I didn't expect that James's TDD course would have such a large impact on the way I develop code. The hands-on exercises got me comfortable with the process, and once I configured my environment to make it easy to running tests, I never stopped.
Read the whole story.
+ More Stories.
See more Stories from the Field. Maybe you can add a story as you grow your iterative development skills.
We're still under construction!
The current price is reduced while we finish creating the curriculum. Over time we expect some of the video content to change and improve. Discounts for early registrants are available. Please contact us.
Your Instructor
James Grenning trains, coaches, and consults worldwide. James’ mission is to bring modern technical and management practices to product development teams, especially embedded systems development.
James got involved in applying Extreme Programming to embedded software in 1999, twenty years into his career. Immediately, he saw the potential that the practices and principles could really help with embedded software development. He put the techniques into action with his client in 1999, confirming the applicability of Extreme Programming practices for embedded software development. That also makes him one of the first XP coaches, before there was Agile.
James was fortunate to have been invited to the meeting where the Manifesto for Agile Software Development was written. He was part of the XP contingent. He invented Planning Poker, an Agile estimating technique used around the world.
James' experience led him to write Test-Driven Development for Embedded C (http://wingman-sw.com/tddec). He is a co-author of CppUTest, a popular unit test harness for embedded C and C++.
Course Curriculum
-
PreviewWhat to expect during Your First Test-Driven Development. (2:39)
-
StartWhy and What of TDD? (18:42)
-
StartQuiz
-
StartDo you want to get better at software development? (0:40)
-
StartPrep Exercise 1.1 Introduction and Preparation (48:11)
-
StartExercise 1.1 -- Your First TDD (duration 60-120 minutes)
-
StartDemo Exercise 1.1 (22:55)
-
StartQuiz
-
StartDebrief your First TDD
-
StartWhat people liked about their first TDD experience (14:06)
-
StartYeah but! -- Initial concerns about TDD.
-
StartTDD will take too long! (7:10)
-
StartI won't be able to think of all the tests! (TDD Guided by ZOMBES) (7:24)
-
StartTDD Guided by ZOMBIES Quiz
-
StartZOMBIES - Impact on Interface (1:58)
-
StartI don't think like that! (7:47)
-
StartHow can I write a test, if I don't know what my code should do? (a.k.a I have third pary dependencies!) (6:29)
-
StartThe steps are so tiny! (4:05)
-
StartTDD means too many lines of code! (1:53)
-
Startl have to maintain the tests! (3:17)
-
StartI have existing legacy code! (2:31)
-
StartI heard that TDD is a waste of time. (1:29)
-
StartOther Concerns and Q&A recorded live. (51:14)