Использование googletest для одновременного запуска модульных тестов для нескольких протестированных модулей

Я работаю над большим проектом C++, который содержит более 50 библиотек и исполняемых файлов. Я начинаю добавлять тесты googletest для каждого из этих модулей. Я читал, что Google рекомендует размещать тесты в исполняемых файлах, а не в библиотеках, чтобы упростить жизнь. Создав отдельный исполняемый файл для каждого отдельного компонента, я получил бы более 50 тестовых исполняемых файлов, и для их одновременного запуска мне нужно было бы создать внешний скрипт, который также должен был бы объединить их вывод в один. Это рекомендуется делать?

Или я должен создать библиотеку для тестов каждого отдельного модуля и связать все эти библиотеки с одним исполняемым файлом тестов? Но тогда запуск тестов для одного модуля становится менее удобным. Мне нужно будет построить все тесты и указать главному исполняемому файлу теста через флаг gtest_filter, какие тесты должны выполняться в это время.

Это действительно помогло бы мне услышать, как другие люди делают это и что здесь лучше всего.

Спасибо


person Leonid Koren    schedule 23.11.2013    source источник
comment
Немного сложно сказать, что должно быть «лучшей практикой» для вашего случая, но я бы пошел в направлении создания отдельных тестовых прогонщиков для каждого из ваших модулей (библиотеки). Собирать выходные данные и объединять их в единый отчет, вероятно, будет проще всего при использовании формата JUnit-XML (и, например, XSLT).   -  person πάντα ῥεῖ    schedule 23.11.2013
comment
Какую систему сборки вы используете? Я думаю, вы должны иметь возможность создать один исполняемый файл теста для всех 50 библиотек, ПЛЮС 50 тестов для отдельных библиотек, если хотите. Мое собственное предложение состояло бы в том, чтобы иметь один исполняемый файл теста, но это личное предпочтение. Каким будет суммарное время выполнения всех тестов? Я бы предпочел иметь один исполняемый файл, чтобы упростить автоматическое тестирование.   -  person NicholasM    schedule 24.11.2013
comment
Спасибо за два комментария. Я предполагаю, что оба подхода, предложенные здесь, могут быть приемлемыми. Я думаю, что на этом этапе я предпочту создать отдельный исполняемый файл для каждого тестируемого компонента и объединить их запуск из одного внешнего сценария, который также будет объединять их выходные данные в один файл.   -  person Leonid Koren    schedule 27.11.2013
comment
@noplk1 - Вы когда-нибудь выясняли, как заставить Google Test работать? Меня смущает документация, и у меня есть вопрос здесь: stackoverflow.com/q/30036984/1735836   -  person Patricia    schedule 04.05.2015


Ответы (1)


[...] и чтобы запустить их все сразу, мне нужно было бы создать внешний скрипт, который также должен был бы объединить их вывод в один.

Возможно, на самом деле нет необходимости объединять вывод в один файл. Например, с помощью Jenkins вы можете указать шаблон подстановочных знаков для выходных файлов Google Test.

Поэтому, если вы на самом деле просто хотите увидеть результаты Google Test в Jenkins (или Hudson, или любом другом инструменте CI, который вы используете), это может быть возможным решением:

Вы запустите все свои тестовые исполняемые файлы из простого сценария (или даже из правила Make) с параметром --gtest_output=xml:, за которым следует имя каталога (т. е. заканчивающееся косой чертой). Затем каждый тестовый исполняемый файл запишет в этот каталог собственный файл XML, после чего вы сможете настроить инструмент CI для чтения всех файлов из этого каталога.

person oliver    schedule 04.11.2015
comment
Все наши проекты создают исполняемые файлы gtest с именами, начинающимися с «gtest», и мы настроили cmake для размещения всех исполняемых файлов в каталоге bin нашего каталога сборки, поэтому я смог перевести это в mkdir -p ${WORKSPACE}/xml/ ; find build/bin -name "gtest*" -exec {} --gtest_output=xml:${WORKSPACE}/xml/{}.xml \;, и затем подстановочный знак работал хорошо, когда я используется xml/build/bin/*.xml (обратите внимание, что find дает полное имя с {}, поэтому необходимы дополнительные каталоги). - person sage; 09.06.2016