Looking at some of the testing I'd like to do in the future

Randall Maas 6/18/2010 1:06:42 PM

Now that I have described how I automated unit tests for embedded system, I would like to discuss some things that I did not get around to. (At least not yet.) Below is a list of some of the kinds of things I'd like to revisit in the future.

  1. I'd like to improve testing to show the code works (or doesn't) well when hardware is failing. I don't want bugs in the failure handling to make a situation worse. This could be done by replacing the procedure it calls with special ones for the test. Ones that emulate a particular degradation or failure. (This is often called "mocks" in object testing contexts.)
  2. I'd like to know if it possible for the procedures to generate a bad calling sequence. There are some techniques for changing the code to allow this type of analysis.
  3. I'd like to know that the software performs reasonably, even if components degrade, and to identify where to focus if I wanted to improve the performance, processing time or power utilization.
  4. Improve how it displays sequences or visual histories, to help understand what leads to (or may lead to) bugs, and to help examine the sequencing to see if it is really what the designer wants.
  5. Expand the catalog of peripherals and microcontroller elements (or models) that it can emulate.
  6. I'd like to know where a value came from ' what other variables, calculations, sources, etc. And I'd like to have better testing that values are reasonably checked (e.g. high, low, etc) and tested.