Constrained Memory is the reality for many embedded developers. Running tests in the development system won’t suffer the same memory constraints found in the target. Here are a few things to help TDD in constrained memory situations.

• First of all, use dual targeting so the bulk of your code is tested off-target. See my paper from the Embedded Systems Conference: Test Driven Development for Embedded Software
• Find a small test harness – Unity is a good choice and can be found on sourceforge.
• Make a lab version of your target system with plenty of memory to hold all production code and test cases.
• Create multiple unit test builds, each with a subset of tests that fit into the limited memory.
• Track memory usage for your target build.

Let’s talk a little about tracking memory usage. Let’s say that your target system has one megabyte of flash memory and you could chart its usage in a graph like this:

Your continuous integration system would build the target flash memory binary image and also create a map file. A simple shell script could read the map file and calculate the code area usage. Each iteration the team pulls that number from the build and puts it on their Big Visible Chart (BVC). When the consumption of this limited resource has an unexpected spike, as in iteration 7, the team can see there is a problem. The build records would reveal when and what was changed to cause the bump in usage. The chart illustrates a drop in flash usage in iteration 8. They must have found some flash hog and put it on a diet.

The team could also establish iteration by iteration budgets of flash or ram usage and set that number in the CI build. The build could fail if the budgeted usage is exceeded, bringing it to the attention of the team immediately during the iteration. The BVC is a very handy tool and could be used for tracking any critical resource like CPU idle time, or IO data rate. You can see that a BVC for resource consumption could give early warning.