файлы сборки модульных тестов

Каковы наилучшие политики для файлов сборки модульного тестирования?

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

Э... проект компилируется... пометить файлы сборки как проверенные и протестированные.

Должен быть лучший способ. Идеи?


unit-testing cmake autotools makefile scons
person deft_code    schedule 13.05.2009    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Вот подход, который мы использовали при создании большой базы кода (много миллионов строк кода) для более чем дюжины платформ.

  • Изменения в Makefile проверяются командой сборки. Эти люди знают об ошибках, которые люди склонны совершать в нашей среде сборки, и именно на них ложится основная тяжесть, когда сборка ломается, поэтому они мотивирован на поиск проблем.
  • Сведите к минимуму то, что должно быть в Makefile, чтобы было меньше возможностей для ошибки. У нас есть слой поверх make, который генерирует Makefile. Разработчик просто должен указать в файле более высокого уровня, используя теги, что, например, данная цель является разделяемой библиотекой или модульным тестом. Обычно цель определяется в одной строке, что приводит к множеству настроек/целей в сгенерированном Makefile. Аналогичные вещи можно сделать с помощью инструментов сборки, таких как scons, которые позволяют абстрагироваться от таких вещей, как детали, специфичные для платформы, делать цели очень просто.
  • Модульные тесты нашего инструмента сборки. Этот инструмент написан на Perl, поэтому мы используем Perl Test::More, чтобы убедиться, что инструмент генерирует правильный Makefile с учетом нашего файла более высокого уровня. Если бы вместо этого мы использовали что-то вроде scons, я бы использовал их среду тестирования.
  • Модульные тесты наших ночных сценариев сборки/тестирования. У нас есть набор сценариев, которые запускают ночные сборки на каждой платформе, запускают инструменты статического анализа, запускают модульные тесты, запускают функциональные тесты и сообщают обо всех результатах в центральная база данных. Мы тестируем различные скрипты по отдельности, в основном с помощью shunit2 фреймворка модульного тестирования для sh/bash. /кш/и т.д.
  • Сквозные тесты нашего процесса сборки/тестирования. Я работаю над сквозным тестом, который работает с крошечным исходным деревом, а не с нашим производственным кодом, поскольку последний может занять несколько часов. строить. Эти тесты в основном направлены на проверку того, что наши цели сборки все еще работают, и сообщают результаты в нашу центральную базу данных даже после, например, обновления нашего инструмента покрытия кода или внесения изменений в наши сценарии сборки.
person Pete TerMaat    schedule 14.05.2009

arrow_upward
2
arrow_downward

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

person philant    schedule 14.05.2009

arrow_upward
-2
arrow_downward

В моих проектах build-файлы меняются не так часто. Более того, я могу повторно использовать файлы сборки из более ранних проектов, только изменив некоторые переменные (которые я переместил в легко узнаваемый раздел). Вот почему мне не нужно проводить модульное тестирование файлов сборки. В других проектах может быть иначе.

person Mnementh    schedule 14.05.2009