Как я могу установить порог покрытия кода как верхний предел в TeamCity?

У меня есть сборка TeamCity, которая фиксирует покрытие кода для юнит-тестов. Я также определил переменную среды для минимального покрытия кода для успешной сборки, которая прекрасно работает, но я не люблю поддерживать этот порог вручную. У меня вопрос: есть ли способ (помимо публикации статистики покрытия кода где-то за пределами TeamCity и последующего чтения результатов последней успешной сборки) автоматически корректировать пороговое значение по мере улучшения покрытия кода, чтобы обеспечить его постоянное улучшение, не допуская откат:)?

Например, предположим, что текущее покрытие кода составляет 20% (унаследованное приложение), а по мере написания новых модульных тестов покрытие кода улучшается до 25%. Затем кто-то регистрирует новый код без юнит-тестов и покрытие кода падает до 24%. Я бы хотел, чтобы TeamCity провалил сборку, потому что охват кода снизился с 25% до 24%.

Источник

3 ответа

Решение

Это старый вопрос, но я хотел бы отметить, что теперь это возможно в более новых версиях TeamCity с помощью функции "Условия отказа". Условия сбоя могут использовать константы, а также сравнивать с ранее сгенерированными метриками. В этом случае условие отказа будет выглядеть так:

Источник

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

Сначала немного контекста:

  • Существует много видов покрытия кода, но я буду говорить только о покрытии линии, но вы должны быть в состоянии заменить другой вид.
  • Из вопроса: "... кто-то регистрирует новый код без юнит-тестов и покрытия кода падает...", который связан с аналогичным: "Кто-то (реорганизует / устраняет дублирование / заменяет алгоритм и) удаляет проверенный код и покрытие падает."
  • Охват должен измеряться в результате выполнения единого набора тестов. То есть не запуская приложение, а стимулируя его извне.
  • Процент покрытия очень вводит в заблуждение.
    Я подумал об этом, и на самом деле вы хотите знать, сколько строк кода НЕ охвачено.
    Смотрите мой комментарий к этому ответу: Обеспечьте минимальный охват новых коммитов Subversion
  • Охват должен быть максимально высоким. Вопрос говорит о "... улучшении без отступления..."
  • Возможно 100% покрытие.
    Я сделал это, хотя и с библиотекой.

У меня есть теория, что вы должны разделить свой код на два раздела, если речь идет о покрытии кода:

  1. Разделение, где весь код покрыт на 100%.
  2. Подразделение, где нет кода.

Любое подразделение может состоять из нескольких проектов, но членами подразделения должны быть файлы (учитывая, что и в Java, и в C# есть исходные файлы) и, предпочтительно, целые папки файлов. Вы можете иметь один набор проектов в первом разделе и другой набор во втором разделе.

Теперь отчет об отсутствии покрытия - это просто количество строк во втором подразделении.

Режим работы должен заключаться в том, что вы тестируете свой код по ходу работы, а код просто попадает в раздел 100% покрытия. Тем не менее, если вы обнаружите сложный фрагмент кода, который ваш мозг просто не может найти способ протестировать, вам следует выполнить рефакторинг, чтобы не проверенные фрагменты переместились во второе подразделение. В качестве альтернативы вы можете получить мозговую волну и найти тест, который поднимает второе деление выше 0%, после чего вы переводите код в первое деление. Это означает, что каждая регистрация поддерживает мой теоретический инвариант.

Теперь вернемся к вопросу:
Нет, я вообще не знаю TeamCity, за исключением краткого обзора сайта JetBrains, поэтому я не знаю, как обновить покрытие, но, согласно моей теории, оно должно составлять 100% или ничего, поэтому вы можете установить ограничения за проект? Если вы можете, то для первого деления действует фиксированный лимит в 100%.
Если вы можете получить два деления, возможно, вы захотите выполнить автоматическое обновление с метрикой строк кода для второго деления, чем ниже, тем лучше.

Источник

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

Если ваш порог изначально был 25, а покрытие перепрыгнуло до 31, обновите его до 30, и теперь оно сломается, если порог упадет ниже 30. Конечно, вы можете сделать это 31, когда произойдет скачок.

Таким образом, после каждого запуска теста вы видите, больше ли текущее покрытие, чем текущий порог, и устанавливаете порог на новое значение?

Источник
Другие вопросы по тегам