有没有人使用过像 CppUnit 这样的包来交叉编译 C++ 单元测试以在嵌入式平台上运行?
我在 Linux 机器上使用 G++ 来编译必须在 LynxOS 板上运行的可执行文件。我似乎无法获得任何常见的单元测试包来配置和构建将创建单元测试的东西。
我看到很多单元测试包,CppUnit、UnitTest++、GTest、CppUTest 等,但很少在交叉编译器场景中使用这些包。带有“配置”脚本的那些暗示这是可能的,但我似乎无法让他们配置和构建。
有没有人使用过像 CppUnit 这样的包来交叉编译 C++ 单元测试以在嵌入式平台上运行?
我在 Linux 机器上使用 G++ 来编译必须在 LynxOS 板上运行的可执行文件。我似乎无法获得任何常见的单元测试包来配置和构建将创建单元测试的东西。
我看到很多单元测试包,CppUnit、UnitTest++、GTest、CppUTest 等,但很少在交叉编译器场景中使用这些包。带有“配置”脚本的那些暗示这是可能的,但我似乎无法让他们配置和构建。
我对交叉编译的单元测试代码的做法是使用本机工具链自行编译单元测试——通常是某种 x86 编译器。这些单元测试在构建机器上而不是在嵌入式目标上执行。如果您正在使用存根和模拟编写严格的单元测试(而不是集成测试),那么您不应该依赖于嵌入式硬件。如果没有……开始永远不会太晚。
这种方法的另一个好处是,对于非 x86 嵌入式目标,这种类型的单元测试有助于清除字节顺序问题、未初始化的变量和其他有趣的错误。
./configure --prefix=/sandBox --build=`config.guess` --host=sh4-linux
sh4-linux 是您要运行程序的平台。
您可能想查看CxxTest。我没有将它用于交叉编译,但它完全基于头文件和 Python 脚本——没有编译库。它可能比其他人更容易适应。
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.
要交叉编译 CppUTest (v3.3),我必须覆盖 LD、CXX 和 CC make 变量。
为了获得 CppUTest 和 CppUTestExt(用于 CppUMock)库及其测试,我使用了 CPPUTEST_HOME 目录中的以下命令:
要构建 libCppUTest.a:
make all LD=sh4-linux-g++ CXX=sh4-linux-g++ CC=sh4-linux-gcc
要构建 libCppUTestExt.a(用于 CppUMock):
make extensions LD=sh4-linux-g++ CXX=sh4-linux-g++ CC=sh4-linux-gcc
然后,您可以将 CPPUTEST_HOME 中生成的 CppUTest_tests 和 CppUTestExt_tests 可执行文件复制到目标设备并在那里执行它们。
假设 CppUTest 在您的目标上通过了它自己的测试,那么您就可以使用 CppUTest 开发您的测试了。只需将您的测试代码与交叉编译的 CppUTest 库链接,然后将生成的可执行文件复制到您的目标。然后运行从目标平台本身获取单元测试结果。
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.