День восемьсот сорок восьмой. #BestPractices #CICD
Индикатор Покрытия Кода
Многие используют непрерывную интеграцию или какой-либо конвейер сборки с помощью Azure DevOps, GitHub Actions или другого сервера сборки. Практически любой из конвейеров позволяет вам запускать тесты как часть процесса и откатывать сборку, если тесты терпят неудачу. Некоторые шаги сборки могут анализировать общее покрытие кода (процент от общего количества строк кода в вашем приложении, которые покрыты тестами), и вы можете выбрать откат сборки, если процент упадёт ниже определённого порога. Это один из индикаторов качества сборки, в данном случае индикатором покрытия тестами.
Важно понимать и убедить руководство в том, что индикатор покрытия тестами - это запаздывающий индикатор.
Суть процесса непрерывной интеграции заключается в сокращении циклов обратной связи. И когда процесс обнаруживает ошибку или неудавшийся тест, он хорошо служит этой цели. Однако, если ваше текущее покрытие кода составляет 85%, а порог качества - 80%, могут произойти несколько ошибочных коммитов, которые уменьшат покрытие (путем удаления тестов или добавления тонны непроверенного кода). Но, возможно, это просто снизит покрытие до 81%. Затем происходят ещё несколько коммитов, которые в принципе нормальные. Но через пару недель - БАМ! – покрытие снижается ниже лимита после вполне безобидного коммита. Настоящий виновник - более ранние коммиты, которые в реальности серьёзно снизили покрытие, но ещё проходили под лимит. А вы обнаружили проблему намного позже.
Если вы собираетесь использовать индикаторы покрытия кода в процессе непрерывной интеграции, то помните, что, в случае унаследованного (существующего) кода, вы должны установить ОЧЕНЬ низкий лимит, а затем увеличивать его каждую неделю или две по мере увеличения покрытия кода. Если вы пишете новое программное обеспечение с относительно высоким стандартом покрытия кода, вам всё равно следует подумать о том, чтобы порог был выше, чем требуют стандарты компании, но всё же чуть ниже текущего покрытия, чтобы всё, что вызывает серьезное падение показателя, было обнаружено на раннем этапе. Возможно, стоит установить более высокий порог в среде разработки, и сделать его чуть ниже для более поздних этапов развёртывания. Если вы отнесётесь к этому серьезно, это может помочь вам быстрее определить, какие изменения в кодовой базе несут ответственность за негативное влияние на покрытие кода.
Источник: https://ardalis.com/tips
Индикатор Покрытия Кода
Многие используют непрерывную интеграцию или какой-либо конвейер сборки с помощью Azure DevOps, GitHub Actions или другого сервера сборки. Практически любой из конвейеров позволяет вам запускать тесты как часть процесса и откатывать сборку, если тесты терпят неудачу. Некоторые шаги сборки могут анализировать общее покрытие кода (процент от общего количества строк кода в вашем приложении, которые покрыты тестами), и вы можете выбрать откат сборки, если процент упадёт ниже определённого порога. Это один из индикаторов качества сборки, в данном случае индикатором покрытия тестами.
Важно понимать и убедить руководство в том, что индикатор покрытия тестами - это запаздывающий индикатор.
Суть процесса непрерывной интеграции заключается в сокращении циклов обратной связи. И когда процесс обнаруживает ошибку или неудавшийся тест, он хорошо служит этой цели. Однако, если ваше текущее покрытие кода составляет 85%, а порог качества - 80%, могут произойти несколько ошибочных коммитов, которые уменьшат покрытие (путем удаления тестов или добавления тонны непроверенного кода). Но, возможно, это просто снизит покрытие до 81%. Затем происходят ещё несколько коммитов, которые в принципе нормальные. Но через пару недель - БАМ! – покрытие снижается ниже лимита после вполне безобидного коммита. Настоящий виновник - более ранние коммиты, которые в реальности серьёзно снизили покрытие, но ещё проходили под лимит. А вы обнаружили проблему намного позже.
Если вы собираетесь использовать индикаторы покрытия кода в процессе непрерывной интеграции, то помните, что, в случае унаследованного (существующего) кода, вы должны установить ОЧЕНЬ низкий лимит, а затем увеличивать его каждую неделю или две по мере увеличения покрытия кода. Если вы пишете новое программное обеспечение с относительно высоким стандартом покрытия кода, вам всё равно следует подумать о том, чтобы порог был выше, чем требуют стандарты компании, но всё же чуть ниже текущего покрытия, чтобы всё, что вызывает серьезное падение показателя, было обнаружено на раннем этапе. Возможно, стоит установить более высокий порог в среде разработки, и сделать его чуть ниже для более поздних этапов развёртывания. Если вы отнесётесь к этому серьезно, это может помочь вам быстрее определить, какие изменения в кодовой базе несут ответственность за негативное влияние на покрытие кода.
Источник: https://ardalis.com/tips