Может ли моя сборка оговорить, что покрытие кода никогда не ухудшится?

Question

Я использую Hudson CI для управления прямым веб-проектом Java, используя Ant для сборки.

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

Есть ли плагин hudson, который работает таким образом?

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

Кроме того, как пояснение, я видел пороги в некоторых плагинах Hudson, но это не совсем то, что мне нужно. Например, мне бы хотелось, чтобы если охват Build # 12 составлял 46%, а кто-то проверял в Build # 13 покрытие 45%, сборка была бы прервана.

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

ОБНОВЛЕНИЕ: Дэн указал на крайний случай с моим планом, который определенно будет проблемой. Я думаю, что мне нужно переосмыслить, является ли это даже хорошей идеей.

Answer 1

Да. Какой инструмент покрытия вы используете?

Плагин Cobertura для Hudson определенно поддерживает это. На экране конфигурации проекта вы можете указать пороговые значения.

В качестве альтернативы вы можете заставить Ant проваливать сборку (а не Гудзона), используя задачу cobertura-check.

РЕДАКТИРОВАТЬ: Я не уверен, что вы можете сделать именно то, что вы просите. Даже если бы вы могли, это может оказаться проблематичным. Например, предположим, что у вас есть среднее покрытие 75%, но для одного класса у вас есть покрытие 80%. Если вы удалите этот класс 80% и все его тесты, вы сократите общий процент покрытия, даже если ни один из других кодов не будет проверен меньше, чем ранее.

Answer 2

Это своего рода хак, но мы используем его по аналогичным причинам с Findbugs и Checkstyle. Вы можете настроить задачу Ant для выполнения следующих действий (их можно разбить на несколько задач, но для краткости я их объединяю):

1. Выполнить тесты с покрытием
2. Разобрать результаты покрытия и получить процент покрытия
3. Чтение tmp / lastCoverage.txt из последней сборки (см. Шаг # 5a)
4. Сравните текущий процент покрытия с процентом, считанным из lastCoverage.txt
5. 1. Если процент НЕ уменьшился, запишите новый процент по сравнению с содержимым tmp / lastCoverage.txt
   2. Если процент DID уменьшится, сохраните исходный файл и откройте «COVERAGE FAILURE» (с заданием ant echo).

Обратите внимание, что шаги 2-5 не обязательно должны выполняться с собственными задачами Ant - вы можете использовать что-то вроде задачи javac Ant, чтобы запустить программу Java, чтобы сделать это для вас.

Затем настройте Hudson:

• В разделе «Управление исходным кодом» убедитесь, что установлен флажок «Использовать обновление». Это позволит сохранить файл lastCoverage.txt между сборками. Обратите внимание, что это может быть проблематично, если вам действительно нужно очищать вещи между сборками.
• Используйте плагин Hudson Text Finder с регулярным выражением для поиска «COVERAGE FAILURE» в выходных данных сборки (убедитесь, что «также поиск консоли выводится» для плагина). Модуль поиска текста может пометить сборку как нестабильную.

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

Как я уже упоминал выше, это довольно странно, но, вероятно, это один из немногих (только?) Способов заставить Хадсона сравнивать вещи из предыдущей сборки с текущей сборкой.

Answer 3

Atlassian's Clover поддерживает то, что вы хотите. Взгляните на задачу clover-check Ant, в частности атрибут historyDir.

Answer 4

Другим подходом было бы использование плагина Sonar для Hudson, чтобы поддерживать тенденцию покрытия с течением времени и облегчать усвоение и анализ результатов. Он также покажет охват в контексте других мер, таких как checkstyle и pmd