I'm thinking about how I can use unit tests in my mcu project, and what frameworks I can use to simplify it.
Today I am using a stm32 with OpenOCD-jtag from a Linux pc, where it is all controlled from a classic Makefile and crosscompiled with gcc.
I could create something myself, but if there is a framework that I can use it would be nice. (It is a bonus if the framework can output the result in a format that Jenkins/Hudson can read).
Is there a way to use a unit test framework with an stm32?
Check out CppUTest, and James Grenning's excellent http://pragprog.com/book/jgade/test-driven-development-for-embedded-c
CppUTest has support for C and C++, and it's got a nice set of Makefile templates that got me started pretty quickly.
There are a lot of variables which will determine the best unit testing framework to use in you situation. Some items which may affect your choice will be:
Most of the xUnit type frameworks will provide some base level of functionality which may be useful. I've used Cunit with some success in the past. (libcunit1-dev package on Ubuntu/Debian). Most frameworks will require libc to be available, some will require additional OS support.
Another altermative which is just 3 lines long is Minunit.
I've found unit testing using the microcontroller as the target to be quite cumbersome as you need to be able to present an environment suitable for downloading tests, running them and then getting results back. Just getting the platform in place which will enable you to do this is a big task.
Another approach that I've taken which has worked for me is to do unit testing on the host, implementing an abstraction layer between the drivers and application code. Since you're using gcc for the target, the code should also compile on the host.
Testing on the compile host is generally so much easier as you have the complete support of the host OS and all its tools. For example, when testing on the host, I have a mocked version of my wireless driver with the same interface as the real driver which runs on the target. The host version uses UDP packets to simulate wireless packet transfer, with the mock driver supporting the ability to drop packets so I can test my protocols.
In the product I was working on, a threaded OS was being used, so the abstraction layer for testing on the host OS used pthreads instead.
While not perfect, the easier it is for you to write and run tests, the more likely you are to implement more test cases. Another benefit of have the code run on different platforms is to test that the code is portable. You'll quickly pick up endian mistakes if the target and host architectures differ.
I'm now a bit off topic, but feel these ideas may help with your choice of test framework and test methods.
Check out embUnit http://embunit.sourceforge.net/embunit/index.html. It is a embedded C unit test framework with a low footprint.
We successfully used it in a couple of embedded microcontroller projects. Don't expect the options and features you get with a desktop unit test framework. But it's definitely powerfull enough.
It has allot of asserts defined for you, so you don't have to lose allot of time writing custom asserts like with minUnit.
Some time ago I wrote a thorough tutorial on the topic: Unit-testing (embedded) C applications with Ceedling; I use these techniques in a bunch of projects, and I'm quite happy so far.
I was just looking into this myself. I found a three part article that outlines a unit test framework here:
I would also agree with everything that Austin has mentioned.
Try lint, but I don't think its for unit testing, its for code analysis.
