I think there is a typical development strategy that a lot of developers use to debug and test their embedded software, which is: compile, program, debug, spot test, adjust then repeat. I have used this process myself for years, after all it felt natural and made a lot of sense.
Unfortunately, there are a lot of issues with this type of development strategy, such as hardware dependency, wasting time programming hardware, spending time debugging, and doing spot checks. Unfortunately, these are often intensive manual “finger crossing” tests. In today’s post, I want to talk a bit about a self-improvement project that I have been working on for several years to improve the way I write and test my own embedded software.
When I was a junior engineer, I came across an interesting and intriguing book that had been published titled Test-Driven Development (TDD) for Embedded C by James Grenning. The premise of the book was that TDD was not just for software developers working on servers and in web applications, but that there was a lot of value that embedded software developers could gain by embracing the principles of TDD. . One of the benefits, which I found irreplaceable in my own software development activities, was the use of an automated test harness.
Test harnesses are fairly well-known tools in use today, but embedded developers still seem to resist their use (depending on their experience and the types of companies they’ve worked for). They allow a developer to write a series of tests that can then be run on their code to detect flaws and verify that the code behaves as it expects. What I like most about them is that I can modify my code and then rerun all of the previous tests I created to find out if I broke anything in my code. If I were to adhere to the “old practices” I would most likely check the code and have a bug that cannot be found waiting to be discovered by a client or user.
I was recently working on a project and wanted to compare the effectiveness of the spot check by running the code on the hardware to verify that the code worked against building a series of test cases. I wrote my code, performed the usual spot checks, and found my code to work great. I felt really good about it. I had written it quickly and put a lot of sweat into it. In fact, I felt like it might be the best, most robust piece of code I have ever written. The question, however, is: would the test harness fit?
So I started writing test cases that would be integrated into cpputest, a C / C ++ test harness, to see what would happen. First of all, during my spot check on the on-board target, I had created around twenty test cases. When I built my test harness, I found out that I had around 36 test cases. I also discovered that when I ran my tests there were no less than five bugs to discover in the module. Now these bugs were extreme cases and they may never have been encountered in the field, but if they had been they could have resulted in some pretty embarrassing system behavior.
The way I used the test harness to compare results to spot checks is not really the right process for someone interested in TDD. In TDD, the developer first writes a test case, then fails it and writes the code to pass it. My experiment was to simply bolt a test harness and a few test cases onto an existing piece of code. The results, however, in my mind, show that there are several important benefits of using automated testing with built-in software, including:
- Creation of tests that continue to verify software integrity even as new features are added
- Creation of known test cases to actually detect a fault
- Force a developer to think about testing and failure modes throughout the development cycle
- Improve code robustness
- Allow a developer to abstract and decouple their application code from the underlying hardware
There are certainly many other benefits out there, but I often see these areas overlooked, and taking a test-like approach instead of TDD delivers a lot of benefits not only for the companies that make the products, but also for the users. final. When I first encountered TDD, I thought it was taking too long and really couldn’t help embedded developers write code faster and more robustly. I no longer have that perspective. In fact, when I start to write a piece of code the first thing I set up is my test harness because without it I feel like I’m going around in circles and developing too slowly.
Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to radically transform their businesses by improving product quality, costs and time to market. He has published over 200 papers on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees including a Masters of Engineering from the University of Michigan. Do not hesitate to contact him at [email protected] on its website www.beningo.com, and subscribe to its monthly Embedded Bytes newsletter.
