Статьи

Сборка и тестирование идут с GoClipse, Drone.io и Coveralls

Июнь 19, 2017

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

Чтобы проиллюстрировать эти статьи на простом примере, я разместил  репозиторий на GitHub,  который преобразует римские цифры в строковой форме в числовой эквивалент. Я добавил поддержку сборки с использованием  drone.io  и покрытие кода с помощью  Coveralls .

Прежде чем попасть туда, стоит отметить, что Go имеет встроенную поддержку для тестирования покрытия кода. Вот команды для получения хранилища кода и запуска его тестов в подробном режиме с включенным покрытием кода:

go get github.com/alanhohn/roman
go test -v --cover github.com/alanhohn/roman

Это дает следующий вывод:

=== RUN   TestValid
--- PASS: TestValid (0.00s)
=== RUN   TestInvalid
--- PASS: TestInvalid (0.00s)
PASS
coverage: 100.0% of statements
ok      github.com/alanhohn/roman   0.009s

Я использую  GoClipse , так как я уже знаком с Eclipse из Java. Он построен на инструментах разработки Eclipse C / C ++ и может быть сконфигурирован без особых усилий для отладки исходного кода, хотя в основном он мне нравится для завершения кода и знакомого сочетания клавиш, которое запускается  gofmt.

Поскольку компиляция и тестирование в Go выполняются очень быстро, я настраиваю GoClipse для запуска тестов с покрытием кода при каждом сохранении. Это означает, что я получаю мгновенную обратную связь не только об ошибках компиляции, но также и о том, сломал ли я модульные тесты и как я справляюсь с освещением. Вот как это выглядит:

Здесь я настроил цель «run-tests» для включения «-cover». Также обратите внимание на маленькую синюю галочку на записи «run-tests» в Project Explorer; это указывает на то, что эта цель сборки будет запускаться автоматически как часть сборки рабочей области.

Теперь, чтобы получить эти зеленые значки. Для добавления проекта Go в drone.io  из репозитория GitHub необходимо  выполнить вход с использованием учетных данных GitHub, авторизовать приложение, нажать «Новый проект» и выбрать репозиторий. Ссылка на значок в Markdown (в разделе «Настройки / Значки состояния») может быть добавлена ​​в файл README.md в корне репозитория Git. Это заставит GitHub отображать значок состояния для сборки.

Чтобы получить значок покрытия кода, я использовал  Coveralls  с  goveralls . Goveralls README предоставляет инструкции для drone.io. Сначала посетите Coveralls, войдите в систему с помощью GitHub и авторизуйтесь. Затем включите хранилище. Скопируйте токен репозитория с правой стороны страницы сведений о репозитории и вставьте его в настройки переменных среды в drone.io для репозитория (в меню «Настройки» / «Построить и проверить»):

COVERALLS_TOKEN=(paste token here)

Наконец, измените команды сборки drone.io на:

go get
go build

go get github.com/axw/gocov/gocov
go get github.com/mattn/goveralls
goveralls -service drone.io

Как и в случае с drone.io, на странице репозитория Coveralls имеется ссылка Markdown для значка readme. Когда все сделано и обновленный файл README.md помещен в GitHub, страница GitHub должна показать что-то вроде этого:

Эти значки будут обновляться автоматически при появлении новых изменений. В дополнение к значкам, drone.io и Coveralls будут хранить подробную информацию о сборках; например, смотрите  историю сборки drone.io  и  историю сборки Coveralls  для моего хранилища римских цифр.

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

32
Share: