Непрерывная интеграция: обеспечить, чтобы новые коммиты были покрыты испытаниями

Я работаю над проектом, который имеет много устаревшего кода, который не покрывается испытаниями.

Можно ли настроить сервер интеграции для проверки того, что все новые коммиты имеют минимальное количество тестов (например, покрытие составляет > 70%)?

По сути, я вижу два варианта:

  • Как-то настроить сервер CI для сбоя сборки, когда совершенные изменения не охватываются модульными тестами. Это гарантирует, что каждый фрагмент нового кода будет иметь тесты и что тесты для устаревшего кода будут увеличиваться с каждым изменением.
  • Установите порог покрытия для всего проекта и не выполните сборку, если процент покрытия уменьшается после фиксации. Проблема заключается в том, что если я удалю класс, содержащий 100 инструкций, и добавлю новый класс с 50 инструкциями, процент покрытия будет расти без меня, когда я буду писать какие-либо тесты.

Мне нравится вариант 1, потому что он заставляет изменения в устаревшем коде тестироваться модулем. Это должно увеличить общий охват тестирования.

Сейчас мы используем Jenkins в качестве нашего CI-сервера и JaCoCo для тестирования. Maven используется для построения проекта, а SVN - наш основной источник контроля.

ОТВЕТЫ

Ответ 1

Я знаю, что вы можете настроить Jenkins, чтобы убедиться, что есть хотя бы один тестовый файл как часть фиксации. Это не обеспечило бы хорошее покрытие тестов, но, по крайней мере, вы бы знали, что произошли какие-то изменения, связанные с тестированием.

Ответ 2

Для варианта 2 вы можете использовать Jenkins JaCoCo plugin для отслеживания охвата кода для каждой сборки и установки результата сборки для передачи или неудачи в зависимости от показателей охвата.

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

  • Разбирайте выходные файлы JaCoCo и найдите классы с охватом 0%
  • Получить файлы, которые были изменены для этой сборки, из деталей ревизии SVN (Jenkins делает номера версий доступными в переменных среды SVN_REVISION, если для этой сборки есть только одна для SVN_REVISION_1, SVN_REVISION_2,... для нескольких)
  • Распечатайте сообщение об ошибке, если какой-либо из измененных классов имеет покрытие 0%
  • Используйте плагин Jenkins Text Finder, чтобы завершить сборку, если напечатано сообщение об ошибке.

Это не полное решение, оно становится более сложным для новых методов или линий, которые не охватываются испытаниями. Дает мне идею для нового плагина Jenkins;-)

Ответ 3

Некоторые средства покрытия (например, cobertura) поддерживают исключение пакетов. Таким образом, вы можете исключить весь старый код (при условии, что он может быть сопоставлен с образцом) и проверить, что кобертура проверяет только новый код (который охватывает новые коммиты).

Надеюсь, это поможет.

Ответ 4

Я создал инструмент, который выполняет именно это

https://github.com/exussum12/coverageChecker

Вы передаете разницу между ветвью и тестовым результатом проверки крышки. Инструмент определяет, какие строки в diff также находятся в файле clover. и не удается построить, если меньше определенного процента

использовать

bin/diffFilter --phpunit diff.txt clover.xml 70

для сбоев, когда менее 70% разницы покрывается тестом

Я могу добавить другие форматы при необходимости

Изменить

Я добавил jacoco

Bin/diffFilter --jacoco diff.txt jacoco.xml