Непрерывная поставка: модульные тесты

В предыдущей статье мы рассматривали статический анализ как один из первых шагов в непрерывной доставке. Наше путешествие продолжится юнит-тестами.

Модульные тесты

Модульные тесты, вероятно, самая важная часть непрерывной доставки. Хотя модульные тесты не могут заменить интеграционные и функциональные тесты, они очень просты в написании и должны выполняться очень быстро. Как и любой другой тип тестов, каждый модульный тест должен быть независимым друг от друга. Что отличает юнит от других типов тестов (интеграционных, функциональных) — это объем. Каждый модульный тест должен проверять только одну единицу кода (метод, класс и т. Д.). Основным преимуществом модульных тестов является то, что они могут рано находить проблемы из-за скорости их выполнения. Когда легкость написания сочетается с очень коротким временем выполнения, неудивительно, что модульные тесты часто составляют большую часть автоматизированных тестов.

Мы не будем углубляться в юнит-тесты. Это огромный предмет, который требует своей статьи.

Разработка через тестирование (TDD)

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

Итак, что такое TDD? Разработка через тестирование (TDD) — это процесс разработки программного обеспечения, который основывается на повторении очень короткого цикла разработки: сначала разработчик пишет (изначально неудачный) автоматический тестовый пример, который определяет желаемое улучшение или новую функцию, затем выдает минимальное количество кода, чтобы пройти этот тест, и, наконец, рефакторинг нового кода в соответствии с приемлемыми стандартами. Кент Бек, которому приписывают разработку или «переоткрытие» методики, заявил в 2003 году, что TDD поощряет простые конструкции и внушает доверие.

Пожалуйста, ознакомьтесь с примером пошагового руководства и рекомендациями по Java для получения дополнительной информации.

Дженкинс

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

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

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

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

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

Чтобы опубликовать результаты теста, мы должны добавить действие после сборки под названием «Опубликовать отчет о результатах тестирования JUnit». В качестве «XML отчета о тестировании» мы должны указать путь «build / test-results / ** / *. Xml».

В отчетах Jenkins JUnit мало что осталось желать лучшего. По этой причине в случае Gradle я предпочитаю использовать «HTML Publisher Plugin». Пожалуйста, установите его так же, как и другие плагины (Управление Jenkins> Управление плагинами> Доступно). Он может быть добавлен в работу аналогично предыдущему плагину. Выберите «Опубликовать отчеты HTML» из списка «Добавить действие после сборки». Нажмите кнопку «Добавить» и в качестве каталога установите «build / reports / tests /». «Сохранить прошлые отчеты HTML» полезно, если требуются исторические данные.

Чтобы увидеть отчеты, которые мы только что сделали, нам нужно выполнить сборку, либо отправив что-либо в хранилище и дождавшись, пока Дженкинс не поднимет его, либо запустив его вручную с помощью кнопки «Build Now» ¹ . Если вы используете тот же репозиторий, который использовался в этой статье, то вам лучше использовать ручную сборку.

Отчеты находятся в самом задании (ссылки «Отчет HTML» и «Результаты последнего теста»). Существует также график, расположенный справа от статического анализа. Более того, одни и те же ссылки появляются внутри каждой сборки только на этот раз, расположенной в левой части экрана.

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

Однако многие организации не могут легко добраться до этой точки. Ошибок будет больше, чем несколько, их исправление займет часы или дни, а не минуты, и руководству потребуются отчеты независимо от результатов. В этом случае пригодятся плагины для отчетов Jenkins. Это не означает, что предложение состоит в том, чтобы идти по этому пути (много ошибок и много времени, пока они не будут исправлены), но реальность часто отличается и что для достижения конечной цели может потребоваться значительное время: true постоянная интеграция, развертывание или доставка.

Travis

В Трэвисе мы ничего не должны делать. Трэвис уже выполняет задачу проверки «Gradle», которая, помимо прочего, выполняет тесты. В отличие от плагинов Jenkins, которые обеспечивают хорошую визуализацию отчетов о тестах, у Travis есть только логи и статусы успешных или неудачных. Мы уже обсуждали плюсы и минусы отсутствия отчетов.

Круг

Как и в случае с Трэвисом, для запуска тестов Circle не требуется ничего особенного. Он уже знает, что Gradle имеет тестовое задание и выполняет его.

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

[Circle.yml]

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

Как только это изменение будет передано в хранилище, Circle сохранит все наши отчеты и сделает их доступными с помощью опции «Build Artifacts», доступной в каждой сборке. Открыв index.html, мы увидим прекрасный отчет Gradle, созданный для нас.

Резюме

Было довольно легко настроить выполнение тестов во всех трех инструментах (Jenkins, Travis и Circle). На самом деле, выполнение уже было выполнено для нас задачей проверки «Gradle», которую мы использовали для статического анализа . Единственное, что нам нужно было сделать, это сообщить Дженкинсу и Серкл, где находятся наши отчеты (у Трэвиса такой роскоши нет).

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

В следующей статье мы рассмотрим покрытие кода. Это поможет нам определить, сколько нашего кода действительно проверено. Оставайтесь в курсе.

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