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

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

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

Ответы [ 3 ]

9 голосов
/ 01 мая 2011

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

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

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

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

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

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

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

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

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

1 голос
/ 21 апреля 2015

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

enter image description here

0 голосов
/ 02 мая 2011

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

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

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

...