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

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

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

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

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

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

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

источник

2013-04-03 Denis Rosca

Имейте в виду, что покрытие 100% не обязательно возможно или даже желательно. Также можно манипулировать номерами покрытия; написание единичного теста для тестового класса может искусственно раздуть ваше тестовое покрытие. –

@MikeRylander Я знаю это, я даже не мечтаю о 100% охвате этого проекта. Но я по-прежнему считаю, что заставлять новые изменения иметь хотя бы некоторое освещение. –

В настоящее время я работаю над решением этой проблемы, которая в основном касается комментария @MikeRylanders. http://pitest.org теперь интегрирован с контролем версий. Следующая версия позволит анализировать файлы по статусу scm. Следующий выпуск позволит провести анализ по диапазону дат или фиксации, что позволит серверу сборки проверить, что модифицированный код соответствует заданной оценке мутации. – henry

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

источник

2013-04-03 18:47:36

Мне не нравится эта идея. Если вы совершаете что-то, чтобы сделать ранее неудачный пропуск теста, вам не нужно также передавать тестовый файл. – JohnnyO

@JohnnyO Теоретически неудачная сборка ** не должна быть совершена в первую очередь. Если ваши юнит-тесты не шелушатся или не привязаны к внешним зависимостям, это другой набор проблем, вам никогда не придется совершать фиксацию, чтобы исправить неисправные модульные тесты. –

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

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

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

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

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

источник

2013-04-03 18:48:09

, но как я могу настроить этот плагин на неудачу, если зафиксированные изменения не покрываются испытаниями? Если я добавлю небольшое изменение в устаревший файл, это может не изменить общую метрику покрытия и, следовательно, не приведет к сбою сборки? –

Правильно, вот почему я включил свои комментарии в свой первый вариант. –

Я с нетерпением жду вашего плагина. –

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

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

источник

2013-04-03 18:50:46

спасибо за ваш вклад, но моя цель состояла в том, чтобы проверить, что новый код протестирован, а также для изменения изменений в устаревшем коде для тестирования. –

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

https://github.com/exussum12/coverageChecker

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

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

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

сбой сборки при менее чем 70% от дифференциала покрывается тестом

я могу добавить другие форматы, если это необходимо

Редактировать

Я добавил jacoco

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

источник

2017-08-17 16:46:27 exussum

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

ответ

Смежные вопросы