Кросс-компиляция модульных тестов с CppUnit или подобным - PullRequest
7 голосов
/ 18 сентября 2009

Кто-нибудь использовал пакет типа CppUnit для кросс-компиляции модульных тестов C ++ для запуска на встроенной платформе?

Я использую G ++ на компьютере с Linux для компиляции исполняемых файлов, которые должны быть запущены на плате LynxOS. Кажется, я не могу заставить ни один из распространенных пакетов модульных тестов настроить и создать что-то, что будет создавать модульные тесты.

Я вижу много пакетов модульных тестов, CppUnit, UnitTest ++, GTest, CppUTest и т. Д., Но очень мало об использовании этих пакетов в сценарии кросс-компиляции. Те, у кого есть скрипт «configure», подразумевают, что это возможно, но я не могу заставить их настраивать и строить.

Ответы [ 6 ]

3 голосов
/ 26 августа 2011
./configure --prefix=/sandBox --build=`config.guess` --host=sh4-linux

sh4-linux - это платформа, на которой вы хотите запустить программу.

2 голосов
/ 25 сентября 2009

Моя практика, когда код для модульного тестирования является кросс-компилированным, состоит в том, чтобы компилировать сами модульные тесты, используя собственный набор инструментов - обычно это разновидность компилятора x86. Эти модульные тесты выполняются на сборочной машине, а не на встроенной цели. Если вы пишете строгие модульные тесты (в отличие от интеграционных тестов) с заглушками и макетами, у вас не должно быть зависимостей от встроенного оборудования. Если нет ... никогда не поздно начать.

Еще одно преимущество этого подхода заключается в том, что для встроенных целей, отличных от x86, этот тип модульного тестирования помогает избавиться от проблем с порядком байтов, неинициализированных переменных и других интересных ошибок.

2 голосов
/ 18 сентября 2009

Возможно, вы захотите посмотреть CxxTest . Я не использовал его для кросс-компиляции, но он полностью основан на заголовках и скрипте Python - нет скомпилированной библиотеки. Может быть легче адаптироваться, чем другие.

0 голосов
/ 27 августа 2013

Для кросс-компиляции CppUTest (v3.3) мне пришлось переопределить переменные make LD, CXX и CC.

Чтобы получить библиотеки 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_tests и CppUTestExt_tests, созданные в вашем CPPUTEST_HOME, на целевое устройство и выполнить их там.

Предполагая, что CppUTest успешно проходит собственные тесты на вашей цели, вы готовы разрабатывать свои тесты с CppUTest. Просто свяжите свой тестовый код с кросс-скомпилированными библиотеками CppUTest и скопируйте полученный исполняемый файл в свою цель. Затем запустите, чтобы получить результаты модульных тестов с самой целевой платформы.

0 голосов
/ 04 января 2011

Похоже, вам нужно иметь библиотеку модульных тестов, скомпилированную для вашей ОС и архитектуры, а также для того, что находится на вашей машине / машинах разработки / сборки. Для этого я предпочитаю платформу модульного тестирования Boost ++. Вы можете скачать что-то, что уже готово для вашей архитектуры, но обычно вам придется скомпилировать это самостоятельно. Я нашел несколько решений путем поиска в Google, как сделать кросс-компиляцию (например, http://goodliffe.blogspot.com/2008/05/cross-compiling-boost.html). CppUnit может быть проще для кросс-компиляции, не пробовал. Общий принцип тот же, вы компилируете ту же версию библиотеки для ваша архитектура разработки и для вашей целевой машины

Моя установка для новых целей состоит в том, чтобы скомпилировать необходимые библиотеки Boost ++ для моей целевой ОС / архива, а затем написать тесты для связи как с библиотеками Boost ++, так и с тестируемым кодом.

Преимущество заключается в том, что вы можете ссылаться на свои библиотеки x86 Linux Boost ++ или на свои целевые библиотеки Boost ++, таким образом вы можете запускать тесты как на своей цели, так и на своих машинах / разработчиках.

Моя общая настройка выглядит следующим образом:

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

Я помещаю скомпилированные библиотеки Boost ++ под разные архитектуры, которые мне нужны в libs / dir для всех моих проектов, и ссылаюсь на эти библиотеки в моих файлах Makefile. Исходный код и тесты получают сборку с переменной arch, указанной для создания команды таким образом, чтобы я мог запустить test_foo.x86 на моем компьютере разработчика и test_foo. {Arm, mips, ppc и т. Д.} На моих целях.

0 голосов
/ 17 марта 2010

Я не даю здесь ответа, но я бы не стал советоваться НЕ запускать ваши юнит-тесты для разных целей: вам все еще нужно, желательно и системные, и юнит-тесты.

В противном случае простые вещи, такие как ошибки выравнивания на ARM / других встроенных процессорах, не будут обнаружены.

...