Как получить отчет по тестированию интеграции Jacoco для работы с Jenkins

Question

Я пытаюсь, чтобы мои интеграционные (JavaAgent) тесты автоматически отображали результаты тестов в Jenkins. В настоящее время я не знаю лучшего способа сделать это, чем

1) Запустите интеграционные тесты, используя JavaAgent, и выведите Jacoco.exec (в настоящее время используется файл).

2) Напишите сценарий оболочки для копирования.exec/.classes/.bin в указанную сборку jenkins.

3) Запустите плагин Jenkins Jacoco, чтобы показать покрытие.

Однако плагин Jacoco не подхватит мой файл.exec. Он только забирает мои уроки, поэтому всегда показывает 0% охват.

Я создал 3 папки: exec, classes, src и скопировал необходимые файлы в эти места. Я вижу, что мои классы правильно читаются на jenkins, но exec-файлы никогда не берутся, несмотря на тот же синтаксис. Я пробовал **/ exec, **/*. Exec, **/jacoco.exec и несколько других. **/classes и **/* Java, кажется, работает, но не для exec.

Answer 1

Это то, что вам нужно.

Например: если у вас есть проект Java, в вашем проекте ProjectABC

• src / main / java: здесь у вас будет основной исходный код
• src/test/java: здесь у вас будет тестовый исходный код. Это юнит-тесты.
• src / xxxTest / java: здесь у вас будет несколько тестовых кодов ххх (где ххх может быть интеграционным тестом, приемочным тестом, тестом селена или каким-либо другим не-модульным тестом.

В зависимости от системы сборки Maven/Ant/Gradle, когда вы будете запускать сборку и тестирование (Примечание: модульные тесты запускаются бесплатно в Maven и Gradle).

Поскольку любая из этих систем сборки использует Java для запуска, после завершения сборки у вас будет один файл jacoco .exec, созданный в JAVA JAVM Maven / Gradle / ANT для ваших модульных тестов. Файл, сгенерированный для модульных тестов, я называю jacocoUT.exec (т.е. файл exec jacoco только для юнит-тестов).

Когда ваша сборка / test / jar / war / etc завершена, у вас теперь есть все, что требуется для запуска файла.war /.ear вашего проекта в Tomcat/ аналогичном контейнере.

Предположим, ваш проект создал файл projectabc.war и вы используете Tomcat.

Вы знаете, что для выполнения любых тестов, не относящихся к юнитам, есть две вещи: 1. Вам нужен Tomcat/ аналогичный - для этого требуется другая JAVA/JVM (то есть, которую будет использовать Tomcat).

2. Вам нужен файл.war, а также файл jacocoagent.jar. Во время выполнения модульных тестов вы сгенерировали бы файл jacocoagent.jar (или вы можете поискать этот файл в Google), если ваши модульные тесты использовали jacoco для генерации покрытия кода.

Теперь это действия, чтобы получить покрытие кода не-модульных тестов (например, для интеграционных тестов)

Сначала я присоединю jacocoagent.jar к сценарию запуска моего Tomcat (сценарию оболочки) и т. Д. Это можно сделать, если добавить следующее в некоторую переменную OPT, которая уже используется в вашем сценарии запуска Tomcat, ИЛИ вы можете создать новую переменную с именем EXTRA_OPTS. ="...", а затем используйте его в скрипте запуска Tomcat. Что вы на самом деле делаете, так это то, что вы можете присоединить jacocoagent.jar к JVM Tomcat (рассматривается как внешняя JVM, так как в этой JVM будет работать файл.war вашего приложения / проекта). Это сделает jacoco видимым для Tomcat сейчас.

Например: допустим, вы создали новую переменную, как указано ниже, и добавили ее в свой скрипт Tomcat startup.sh (когда вы запустите Tomcat, она будет выбрана).

export PROJ_EXTRA_JVM_OPTS="-javaagent:tomcat/jacocoagent.jar=destfile=somefolder/in/your/workspace/build_or_target_or_somecustom_folder/jacoco/IT/jacocoIT.exec,append=false"

ПРИМЕЧАНИЕ. Здесь я помещаю файл jacocoagent.jar в папку tomcat. Вы можете поместить его где угодно и использовать этот путь для файла jacocoagent.jar для переменной javaagent.

Теперь в сценарии startup.sh вашего Tomcat вы можете добавить эту переменную, где фактически запускается Tomcat. Например, снимок этого сценария запуска будет выглядеть так:

## Tomcat command
TOMCAT_CMD="$JAVA_HOME/bin/java $TOMCAT_JVM_ARGS \
$OPTIT_JVM_ARGS \
... \
... \
$PROJ_EXTRA_JVM_OPTS \
-Dthc.tomcat.extrapaths=$TOMCAT_EXTRA_PATHS \
org.apache.catalina.startup.Bootstrap $TOMCAT_CFG_FILE_ARGS start"

Как вы видите выше, теперь созданная мною переменная теперь используется, пока Tomcat запускается (когда мы запускаем переменную TOMCAT_CMD, которая имеет командную строку).

Теперь, когда вы поместите.war-файл в папку tomcat / webapps и запустите скрипт Tomcat для startup.sh, вы увидите новый файл jacocoIT.exec по указанному пути (0 байт в настоящее время, поскольку вы не запускали никаких Юнит тестов пока нет).

На этом этапе Tomcat будет запущен и запущен, а файл.war вашего проекта будет развернут в папку в папке tomcat / webapps +, если проект является приложением, а затем на каком-нибудь компьютере (localhost / ip xxxx: port/yourCoolApp) работает, Теперь он готов к вашим тестам, не относящимся к юнитам (например, тесты Integartion / приемочные тесты / тесты на основе селена и т. Д.). Для запуска любых тестов, не относящихся к юнитам, вам нужен Tomcat/ аналогичный контейнер с файлом.war /.ear и т. Д. Вашего проекта.

ХОРОШО. На этом этапе вы теперь запустите свои интеграционные тесты. Вы заметите, что если вы выполняете файл (tail -f catalina.out), то в файле журнала catalina.out происходит какое-то действие / попадание, поскольку интеграционные тесты выполняются / выполняются.

На этом этапе ваш файл jacocoIT.exec по-прежнему (0 байт или несколько байтов) зависает, поскольку это еще не действительный / заполненный файл покрытия кода jacoco для ваших ИТ-тестов.

Допустим, что ваши ИТ-тесты (Gradle / Maven) завершены, и вы окончательно остановите свой Tomcat (скажем, запустив какой-нибудь скрипт оболочки stopTomcat.sh).

На этом этапе вы получите полностью заполненный файл jacocoIT.exec (так как после того, как вы остановили свой экземпляр Tomcat, он сбросит все данные покрытия кода в файл jacocoIT.exec).

В зависимости от того, запускали ли вы IT или AT (приемочные тесты) или ST (тесты селена), вы можете соответствующим образом назвать файл jacocoXX.exec.

Итак, вы завершили запуск Tomcat + запуск ИТ-тестов + остановка Tomcat + получение действительного / заполненного файла jacocoIT.exec.

ПРИМЕЧАНИЕ. Важно остановить Tomcat, чтобы получить заполненный файл jacocoIT.exec, иначе это не будет действительный файл покрытия кода. После остановки Tomcat размер файла увеличивается, что является еще одним признаком того, что у вас есть что-то хорошее.

Вам не нужно останавливать tomcat, если вы каким-то образом используете дамп данных покрытия кода в коде своего приложения или используете tcp для сбора данных покрытия кода. Это полезно, когда вы не хотите останавливать экземпляр Tomcat (то есть, если вы хотите получить покрытие кода ИТ-тестами в среде INT, QA и т. Д., Где приложение должно быть запущено и работает). Посмотрите документацию jacoco, как вы можете получить покрытие кода без остановки экземпляра контейнера Tomcat/ аналогичного приложения.

Все, что вам нужно сделать сейчас, это получить этот файл jacocoIT.exec (тесты интеграции), расположенный рядом с файлом jacocoUT.exec (модульные тесты), а затем использовать шаблон "**/*. Exec"; в основном используются оба файла.exec (или несколько файлов.exec для различных выполненных вами тестов), чтобы получить покрытие кода.

Это то, что я сделал в Дженкинс.

1. Основное задание проекта, проверяет код, запускает сборку (включая тесты) и в рабочей области основного задания у меня есть файл jacocoUT.exec (если существуют модульные тесты, и они запускаются).

2. Я запускаю / вызываю другое дочернее / нижестоящее задание для запуска ИТ-тестов и выполняю следующее (во время этого дочернего задания основное задание ЗАБЛОКИРОВАНО / выполняется, пока дочерний процесс не завершит свою работу): a. checkout, используя то же изменение / ревизию, укажите, какое основное задание сборки использовалось для извлечения, а затем экспортируйте эту переменную PROJECT_EXTRA_JVM_OPTS. В скрипте запуска Tomcat он уже используется. Здесь я передаю, что мой тип тестов - IT, то есть он создаст файл jacocoIT.exec. б. Я использую плагин Copy Artifact и получаю JAR-файл.war и jacocoagent из рабочей области LATEST основного задания сборки и помещаю файлы в соответствующие места. с. Я начинаю Tomcat d. Я запускаю интеграционные тесты. е. Я останавливаю Tomcat F. Я запускаю / публикую отчет jacoco (jacocoTestReport в Gradle) или плагин Jacoco в Jenkins. Это ТОЛЬКО отчет jacoco для ИТ-тестов (используется только файл jacocoIT.exec).

3. Теперь управление возвращается к основному проекту / сборке, и здесь я использую a. Скопируйте плагин артефакта снова. На этот раз, чтобы получить файл jacocoIT.exec из рабочей области задания CHILD и поместить его в какую-то папку / папку, где файл jacocoIT.exec находится рядом с jacocoUT.exec (т. Е. Build/jacoco/UT/jacocoUT.exec и build/jacoco/IT/jacocoIT.exec).

4. Теперь я могу легко использовать Jacoco (задание Gradle's jacocoTestReport) ИЛИ Jacoco Plugin (**/*. Exec pattern), чтобы показать / получить / опубликовать покрытие кода COMBINED Jacoco (как для модульных, так и для интеграционных тестов). Если у вас более двух типов тестов, таких как, например, jacocoST.exec (для тестов на селен), вы можете получить их, и тогда вы получите комбинированное покрытие кода, используя 3 теста.

ПРИМЕЧАНИЕ. Покрытие кода позволяет узнать, сколько кода (различных счетчиков) вы покрываете в ГЛАВНОМ исходном коде во время выполнения тестов (модуль / интеграция / и т. Д.).

5. Наконец, я вызываю sonarRunner (задача Gradle) или анализ сонара и задаю свойства Sonar для чтения файлов.exec, других значений свойств и получения комбинированных отчетов также в Sonar. Вы должны заглянуть в "Плагин Views Views" в SonarQube (и посмотреть, что он делает). Используя плагин портфолио, вы можете создавать различные виды и показатели верхнего уровня в Sonar для различных команд, людей, типов проектов и т. Д. И получать комбинированные метрики Sonar.