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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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