CODEWITHSUNDEEP
c++unit-testingcross-compiling
Mark
Mark

Reputation:

Cross compiling unit tests with CppUnit or similar

Has anyone used a package like CppUnit to cross-compile C++ unit tests to run on an embedded platform?

I'm using G++ on a Linux box to compile executables that must be run on a LynxOS board. I can't seem to get any of the common unit test packages to configure and build something that will create unit tests.

I see a lot of unit test packages, CppUnit, UnitTest++, GTest, CppUTest, etc., but very little about using these packages in a cross-compiler scenario. The ones with a "configure" script imply that this is possible, but I can't seem to get them to configure and build.

Upvotes: 8

Views: 6023

Answers (6)

doughgle
doughgle

Reputation: 835

To cross-compile CppUTest (v3.3), I had to override the LD, CXX and CC make variables.

To get both the CppUTest and CppUTestExt (for CppUMock) libraries and their tests built I used the following commands from the CPPUTEST_HOME directory:

To build libCppUTest.a:

make all LD=sh4-linux-g++ CXX=sh4-linux-g++ CC=sh4-linux-gcc

To build libCppUTestExt.a (for CppUMock):

make extensions LD=sh4-linux-g++ CXX=sh4-linux-g++ CC=sh4-linux-gcc

You can then copy the CppUTest_tests and CppUTestExt_tests executables that are produced in your CPPUTEST_HOME to your target device and execute them there.

Assuming CppUTest passes it's own tests on your target, you're then ready to develop your tests with CppUTest. Just link your test code with the cross-compiled CppUTest libraries and copy the resulting executable to your target. Then run to get unit test results from the target platform itself.

Upvotes: 1

yaohuaxin
yaohuaxin

Reputation: 31

./configure --prefix=/sandBox --build=`config.guess` --host=sh4-linux

sh4-linux is the platform where you want to run the program.

Upvotes: 3

Misha M
Misha M

Reputation: 11299

It sounds like you need to have unit test library compiled for your OS and architecture as well as what's on your dev/build machine(s). I prefer Boost++ unit test framework for this. You can either download something that's prebuilt for your architecture, but will usually have to compile it yourself. I found a few solutions by googling for how to cross-compile boost (e.g. http://goodliffe.blogspot.com/2008/05/cross-compiling-boost.html). CppUnit might be easier to cross-compile, haven't tried. The general principle is the same, you compile the same library version for your development architecture and for your target machine

My setup for new targets is to compile the necessary Boost++ libraries for my target OS/arch and then write tests to link against both Boost++ libraries and the code to be tested.

The benefit is that you can link against your x86 Linux Boost++ libs or against your target Boost++ libs, thus you can run the tests on both your target and your dev/build machine(s).

My general setup looks like this:

libs/boost/<arch>/<boost libs>
src/foo.{cpp,h}
tests/test_foo.cpp
build/foo
build/test_foo.<arch>

I put compiled Boost++ libs under different architectures that I need in libs/ dir for all my projects and reference those libs in my Makefiles. The source and the tests get build with an arch variable specified to make command that way I can run test_foo.x86 on my dev machine and test_foo.{arm,mips,ppc,etc.} on my targets.

Upvotes: 0

kert
kert

Reputation: 2271

Im not providing an answer here, but i wouldn't take the advice of NOT running your unit tests on different targets : you still need to, preferably both system and unit tests.

Otherwise simple things like alignment errors on ARM/other embedded CPUs will not get caught.

Upvotes: 2

David Joyner
David Joyner

Reputation: 23167

My practice when unit testing code that is cross compiled is to compile the unit tests themselves using the native toolchain -- usually some flavor of x86 compiler. These unit tests execute on the build machine rather than on the embedded target. If you're writing strict unit tests (as opposed to integration tests) with stubs and mocks you shouldn't have dependencies on embedded hardware. If not... it's never too late to start.

One added benefit of this approach is that for non-x86 embedded targets, this type of unit testing helps flush out endianness issues, uninitialized variables and other interesting bugs.

Upvotes: 3

Steve Fallows
Steve Fallows

Reputation: 6424

You might want to look at CxxTest. I have not used it for cross compilation, but it is based entirely on headers and a Python script - no compiled library. It might be easier to adapt than others.

Upvotes: 2

Related Questions