Использование фрейма контрольного блока во встроенном устройстве?

Question

Кто-нибудь использовал проверку в качестве модульной тестовой среды во встроенном устройстве, которая также требует кросс-компиляции?

Это даже хорошая идея, или я должен просто использовать что-то еще (например, embunit или подобное)?

Если да, то как мне написать Makefile.ams и configure.ac? Я не использовал autotools для начала, поэтому все эти материалы кросс-компиляции, безусловно, не помогают ...

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

Что было бы минимальными файлами, которые мне нужны? В примерах все компоненты конфигурации, и я не могу понять, что я могу оставить.

Answer 1

Насколько я вижу, «проверка» использует системный вызов fork(). Если вы не используете операционную систему UNIX на встроенной цели, вы столкнулись с проблемами здесь. На странице check manual page в главе 2.1 вы найдете хороший обзор альтернативных структурных модулей. Большинство фреймворков полагаются либо на некоторые вызовы операционной системы, либо на некоторые стандартные функции библиотеки, которые могут отсутствовать в вашей встроенной цели.

Я нашел макроэкспрессионную модульную структуру тестирования MAESTRA очень полезен для встроенных платформ. Несколько лет назад была интересная статья о embedded.com: Doing C code unit testing on a shoestring.

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