Embedded systems code with good unit tests?

I am looking at approaches to Unit Test embedded systems code written in C.

At the same time, I am also looking for a good UT framework that I can use. The framework should have a reasonably small number of dependencies.

Any great Open-source products that have good UTs?

EDIT:

Folks, thanks for the answers --I really appreciate them, but this does not directly answer my question:

Do you kn开发者_运维技巧ow of any Open-source code that uses C Unit Tests? I am looking to see how it's done, so that I can learn something from the code...

---

Modularize your code in such a way that there is a thin layer in the bottom which knows about the details of the underlying hardware. That layer can then be mocked on a normal PC. That way you can use normal unit test libraries for desktop development to test all code except that thin bottom layer.

My experience on developing embedded software for Linux is using C++ and not plain C. We used cppunit for unit tests.

---

Edit: there is a list of project using Check as unit test framework on the check project page. Some links are outdated, but you can browse the source of the unit test of pigment and SCEW ; one has to download the source for others.

---

minunit has no dependencies at all and can be used as a base to build your own framework.

As far as an approach is concerned, I start from the lowest level functions (the leaves). Very often, when I'm testing the higher level function they invoke the lower level functions. This is not a problem as the lower functions have already been tested.

I also modularize the code as "object", or table of objects. Stub functions allow testing in isolation of the hardware or of other components.

I get rid of the static with a define that remove them, or I include the source file containing the functions to be tested into the unit tests source file.

#if defined(UNIT_TESTING)
#define STATIC
#else
#define STATIC static
#endif

No rocket science here but this does the trick.

One last thing, test the behavior, not the implementation so that the unit tests won't break when the implementation changes.