|
I identified CUnit, EmbeddedUnit, and μCUnit as feasible choices.
It is quite hard to find a unit testing framework in embedded world, compared to Java or any desktop OS-based programming language. Cross-platform development is to build software on PC, then transfer to the target board. This causes a big constraint on how to activate code, input arguments, and get the result. Normally unit testing is to verify and catch differences in actual output and expected output for each function, in an automated sense. C language provides assert function to trap status differences, that is ok for logical and application layers, but not hardware abstraction layer. If we would like to catch physical output, we need to develop our own automated instruments around the processor board. Some automotive devlopment firms make use of hardware-in-loop device, that is very expensive. In my openion, you may consider a procedure for human testers and a guideline on functional testing of embedded hardware. That should be a more realistic solution.
I would like to hear more about the advantages of having a unit testing "framework". Given that you have resource restrictions, I assume you are working on a small-scale project. Most of my projects are small-scale PIC projects programmed in C. There is no OS involved. We test by embedding test functions in the source code. The tests are selected at compile time using #def and included in the compiled code using #ifdef . We generally write code and test using a bottom-up methodology. As you may well know, for small-scale systems, determining the method for communicating the results of such tests sometimes requires creativity. For message passing we sometimes use an asynchronous serial link (if a UART is available) ... however, for very small systems, the strings themselves may strain RAM resources. For real-time systems, asynchronous message passing may break time-critical functions ... so sometimes just flipping a bit or two and observing on an oscilloscope works to communicate the results of a test. The bottom line is, testing as I've described above gives us complete control and assures that testing does not interfere with performance. I'm wondering what advantages a "testing framework" would provide and what types of systems they are best suited for.
considering my point of view for embedded system Arduino is the good platform.you have open source software for writing and downloading codes to Arduino board. language is much similar to basic c. knowledge of c will be helping a lot. many versions of arduino are avilable according to requirements.same software is enough. low cost. smaller in size compared to other hardwares of Um units
|
Normally unit testing is to verify and catch differences in actual output and expected output for each function, in an automated sense. C language provides assert function to trap status differences, that is ok for logical and application layers, but not hardware abstraction layer. If we would like to catch physical output, we need to develop our own automated instruments around the processor board. Some automotive devlopment firms make use of hardware-in-loop device, that is very expensive.
In my openion, you may consider a procedure for human testers and a guideline on functional testing of embedded hardware. That should be a more realistic solution.
Kevin Austin
Savnaya mv
considering my point of view for embedded system Arduino is the good platform.you have open source software for writing and downloading codes to Arduino board. language is much similar to basic c. knowledge of c will be helping a lot. many versions of arduino are avilable according to requirements.same software is enough. low cost. smaller in size compared to other hardwares of Um units