Непрерывная доставка: покрытие кода

Эта статья является частью серии « Непрерывная интеграция, доставка и развертывание ».

В предыдущей статье мы рассмотрели модульные тесты как первый и самый быстрый набор тестов, который мы должны выполнить. Теперь пришло время посмотреть, обеспечивают ли наши модульные тесты достаточное покрытие кода.

Покрытие кода

Модульные тесты сами по себе не обеспечивают достаточной уверенности, если только мы не знаем, что они охватывают значительный охват кода. Успешное выполнение всех тестов, в том числе, например, только 15% кода, не может обеспечить достаточного доверия.

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

Что такое покрытие кода?

Покрытие кода — это мера, которую мы используем для проверки того, какая часть нашего исходного кода была протестирована. Чем выше охват кода, тем больше процент нашего кода был протестирован.

Важно понимать, что покрытие кода напрямую не связано с качеством кода. Высокий охват кода не гарантирует высокое качество этих тестов. Например, даже при 100% охвате кода нет гарантии, что определенные функции были разработаны правильно или вообще не были разработаны.

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

Для получения дополнительной информации, пожалуйста, обратитесь к Кодекс и Покрытие теста

Давайте посмотрим, как мы можем реализовать покрытие кода в наших инструментах CI / CD.

Дженкинс

Для тех из вас, кто не следовал за предыдущими статьями подробно, или тех, кто не смог воспроизвести все упражнения, пожалуйста, установите Vagrant и клонируйте код из репозитория TechnologyConversationsCD . Чтобы создать виртуальную машину с заданием Jenkins и myFirstJob, которое выполняет статический анализ, перейдите в каталог Servers / jenkinsWithTests внутри клонированного репозитория и выполните следующее:

Если это не первый раз, когда вы запускаете эту бродячую виртуальную машину («vagrant up» настроен на запуск контейнера Docker только в первый раз) или по какой-то причине контейнер Docker не работает, его можно запустить с помощью следующего сценария быстрого доступа ,

Мы можем проверить, какие контейнеры запущены, выполнив:

После завершения виртуальная машина с заданием Jenkins и myFirstJob будет запущена и запущена. Результаты можно увидеть, открыв http: // localhost: 8080 в браузере.

Мы продолжим использовать Gradle в качестве инструмента для сборки. В прошлой статье мы выполняли проверку задачи Gradle для запуска статического анализа (CheckStyle, FindBugs и PMD) и тестов. Теперь мы добавим покрытие кода с помощью JaCoCo .

Чтобы добавить покрытие кода JaCoCo, все, что нужно сделать, это добавить плагин в файл build.gradle .

Хорошей новостью является то, что если плагин JaCoCo используется, он добавляет себя к проверке и тестированию задач Gradle. Поскольку у нас уже есть задание Jenkins, которое выполняет задачу проверки Gradle, ничего не нужно делать, чтобы сообщить JaCoCo о сборе статистики наших тестов.

Однако JaCoCo нужно два исполнения. Один из них — начать сбор данных из наших тестов (уже описанных в задаче проверки Gradle). Второй — генерировать HTML-отчет из собранных данных. Для этого мы должны изменить наш вызов Gradle по сравнению с заданием Jenkins myFirstJob, добавив jacocoTestReport в список задач Gradle. Теперь это должно выглядеть так:

Чтобы опубликовать отчеты о покрытии JaCoCo, нам нужно установить плагин JaCoCo (Jenkins> Управление Jenkins> Управление плагинами> Доступно). После установки плагина мы можем добавить действие после сборки под названием «Запись отчета о покрытии JaCoCo». В качестве «Путь к файлам exec» укажите « / .exec» (JaCoCo сохраняет данные покрытия в файл .exec). «Путь к каталогам классов» должен быть установлен в « / classes», чтобы все те, что были ранее скомпилированы с Gradle, включены. Наконец, мы должны установить «Путь к исходным каталогам» в « / src / main / java». Остальные параметры связаны со здоровьем покрытия и зависят от предпочтений команды. Я склонен считать покрытие кода приемлемым на 90%. Более 95% часто контрпродуктивно.

Вот и все. Мы готовы создать myFirstJob с включенным покрытием кода JaCoCo. Нажмите кнопку «Build Now» ¹ в левом меню. По завершении выполнения задания введите сборку и нажмите «Отчет о покрытии». Он покажет отчет с охватом инструкций, веток, сложности, линий, методов и классов.

Интегрировать JaCoCo в Jenkins довольно легко. Сложная задача — добраться до точки, где охват кода тестами достаточно высок. Твердое понимание TDD, функциональное и интеграционное тестирование (я предпочитаю BDD ) — это ключ.

Travis

Трэвис не очень хорошо играет с JaCoCo. Конечно, легко пройти через Gradle так же, как мы это делали с Дженкинсом. Однако нет простого способа получить и опубликовать результаты. В случае результатов теста невозможность публикации не является проблемой, так как нас интересует только то, есть ли какой-то неудачный тест, и можем легко увидеть из журналов, какой из них провалился. Поскольку неудачные тесты должны быть исправлены как можно скорее, для отчетов нет реальной причины. Покрытие кода отличается. Поскольку в большинстве случаев покрытие кода, полученное с помощью тестов, не составляет 100%, способность видеть и просматривать результаты важна.

CircleCI

Как и в случае с Travis, CircleCI не требует каких- либо специальных действий для выполнения покрытия кода, поскольку он является частью проверки задачи Gradle (при условии, что мы добавили плагин JaCoCo Gradle).

Мы уже видели в предыдущей статье, что Circle очень похож на Travis в своем подходе к CI. Основное отличие заключалось в стабильности и скорости (это в несколько раз быстрее, чем у Travis). С покрытием кода мы можем исследовать другое отличие. У Circle есть возможность хранить артефакты сборки. С ними мы можем добиться эффекта, подобного тому, что мы сделали с Дженкинсом. Мы позволим пользователям видеть покрытие кода Gradle вместе с другими типами отчетов. Все, что нам нужно сделать, это изменить наш файл circle.yml, добавив jacocoTestReport и убедившись, что все отчеты добавляются в артефакты CircleCI.

[Circle.yml]

Полный исходный код можно найти в circle.yml .

Как только это изменение будет передано в хранилище, CircleCI сохранит все наши отчеты и сделает их доступными с помощью опции «Артефакты», доступной в каждой сборке. Открыв jacoco / test / html / index.html, мы увидим хороший отчет, сгенерированный для нас JaCoCo.

Резюме

Было довольно легко настроить покрытие кода и публиковать результаты как в Jenkins, так и в CircleCI. Единственное, что нам нужно было сделать — это сказать им, чтобы они запустили задачу Gradle jacocoTestReport и где найти результаты. Travis, с другой стороны, не имеет возможности публиковать отчеты. Без них покрытие кода практически бесполезно.

Дженкинс продолжает сиять своей системой плагинов. «Build Artifacts» от Circle стал приятным сюрпризом и еще одним удобным дополнением к его скорости. Чем больше я его использую, тем больше я вижу преимущества по сравнению с Travis. Цена Трэвиса была непобедима (публичные репозитории бесплатны). Тем не менее, с недавних пор CircleCI также бесплатен, предоставляя более быстрые сборки и несколько приятных дополнений (например, хранение артефактов).

В следующей статье мы рассмотрим заключительный этап непрерывной доставки и развертывания. Цель состоит в том, чтобы постоянно развертывать (или, по крайней мере, доставлять) программное обеспечение. Непрерывный в этом случае означает часто, быстро и с нулевым временем простоя. Оставайтесь в курсе.

1. Слово предостережения: не забудьте стереть рабочее пространство ([JOB]> Workspace> Wipe Out Current Workspace), если выполняете одну и ту же сборку несколько раз, не внося никаких изменений в код. Gradle обнаружит, что изменений нет, и ничего не сделает. Это хорошо, так как таким образом можно сэкономить много времени, но это может вызвать некоторую путаницу при тестировании конфигурации работы Jenkins.