Что такое code coverage и как вы его измеряете?

December 2021

В среде Windows можно использовать параметр  --collect "Code Coverage"  Для вычисления процента кода к которому обращаются тесты будет использоваться Cobertura. Одни инструменты, такие как istanbul, выводят результаты прямо в терминал, а другие — могут генерировать полный HTML-отчет, из которого можно понять, какая часть кода не покрыта. Если в проекте тестов не было вообще, то эта статистика начинает быстро расти. А вот дальше, ближе к 90 процентам, придется бороться за каждую строчку кода.

Второй запуск нашего инструмента покрытия покажет, что покрыто 100 % исходного кода, благодаря наличию двух операторов console.log() внизу. BTW, в то время как code coverage - это хорошая метрика того, сколько тестирования вы делаете, это не обязательно хорошая метрика того, насколько хорошо вы тестируете ваш продукт. Есть и другие метрики, которые вы должны использовать вместе с code coverage для обеспечения качества.

Особенности в измерении покрытия кода

Теперь ветвь main защищена пайплайном который мы разработали. При попытке сделать PR в ветку запустится пайплайн и в случае снижения процента покрытия кода, остановится с сообщением, что процент покрытия кода снизился относительно последней проверки. Назначение модульных тестов состоит в том, чтобы гарантировать работоспособность отдельных методов классов и компонентов, используемых приложением. Они, как правило, не затратны в смысле реализации, быстро выполняются и дают вам полную уверенность в том, что основа платформы надежна. Простой способ быстро увеличить покрытие кода — начать с добавления модульных тестов, поскольку они по определению должны помочь комплекту тестов достигать всех строк кода. В этом примере мы просто регистрировали результаты в терминале, но тот же принцип применяется и при запуске комплекта тестов.

Скоро в вашем коде будет так много тестов, что вы перестанете понимать, какая часть приложения проверяется во время выполнения комплекта тестов. Вы узнаете, что сломалось, когда получите сборку с ошибкой, но вам будет сложно понять, какие компоненты успешно прошли тестирование. Что касается того, как мы его используем - code coverage - это один из наших критериев выхода на каждый этап. У нас на самом деле есть три метрики code coverage - покрытие из юнит-тестов (из команды разработчиков), scenario tests (из команды разработчиков) и комбинированное покрытие.

Шаги пайплайна с Code Coverage и Build Quality Checks

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

• После запуска инструмента покрытия кода мы получим отчет о покрытии, показывающий показатели покрытия.
• Таким образом когда подход к тестированию, метрики и процент покрытия будет выработан, если есть потребность можно жестко регламентировать требования к покрытию тестами.
• Если вы всегда ударяете по ветке "YES", вы не покрываете часть "else" и это будет показано в результатах покрытия кода.
• Здесь отчеты о покрытии могут служить источником направляющих указаний для вашей команды.

В следующей статье будет добавлен важный этап настройки template pipeline для репозитория с большим количеством сервиса. Это нужно на случай если сервисы вашей платформы или веб приложения разрабатываются различными командами. Тогда Quality Gate пайплайн не должен блокировать разработку других сервисов. В приведенном ниже простейшем скрипте у нас есть функция JavaScript, проверяющая, является ли аргумент кратным числу 10. Ниже мы воспользуемся этой функцией, чтобы проверить, кратно ли число 100 числу 10.

Quality Gate: настройка проверки Code Coverage для микросервисов .Net Core в Azure DevOps

Эти показатели обычно выражаются как количество фактически протестированных элементов, количество найденных в коде элементов и процент покрытия (количество протестированных элементов/количество найденных элементов). Насколько я иду об отслеживании покрытия юнит-тестами на своих проектах, я использую статические средства анализа кода, чтобы отслеживать. На скриншоте выше видно что проверка обязательна при PR в ветку с включенной политикой "Build Validation". Появилось сообщение о снижении покрытия кода и билд остановился. Для сбора данных об объема протестированного кода будем использовать сборщик Coverlet с помощью параметра --collect "XPlat Code Coverage". Это межплатформенный вариант, основанный на .NET CLI, который отлично подходит для систем сборки, в которых недоступен MSBuild.

Это поможет понять разницу между покрытием функций и покрытием веток. Если вы магазин C++, в Intel есть какие-то tools, которые запускаются для Windows и Linux, правда я им не пользовался. Также я слышал есть инструмент gcov для GCC, но я ничего не знаю об этом и не могу дать вам ссылку. Покрытие кода - это замер того, сколько строк/блоков/арков вашего кода исполняется во время работы автоматизированных тестов. Можно, так же, просто перейти и посмотреть настроенный пайплайн и код (понадобится учетная запись Visual Studio или GitHub, процесс регистрации максимально простой).

Atlassian Together

Если ваша цель — 80-процентное покрытие, в качестве подстраховки рассмотрите возможность установить порог отказа на уровне 70 % для сохранения культуры CI. Чтобы определить, насколько хорошо был испытан код во время выполнения комплекта тестов, инструменты покрытия кода будут использовать один или несколько критериев. К числу типичных показателей, которые можно встретить в отчетах о покрытии, относятся следующие.

Таким образом, высокий процент покрытия кода говорит о том, что большая часть программы была протестирована, и вероятность обнаружения ошибок или неправильного поведения уменьшается. Code coverage (покрытие кода) — это метрика, используемая в разработке программного обеспечения для измерения объема и степени исполнения (покрытия) исходного кода программы в процессе тестирования. Эта метрика позволяет оценить, насколько хорошо тесты проверяют различные части программного кода.

Покрытие кода тестами (Code Coverage)

Важно понимать, что оно не является единственным критерием качества программы. Например, в приведенном выше примере мы достигли покрытия в 100 %, выполнив тестирование того, являются ли числа 100 и 34 кратными 10. Но что если мы вызовем нашу функцию, передав ей букву вместо числа? Важно дать команде время подумать о тестировании с точки зрения пользователя, чтобы тесты не выполнялись лишь путем просмотра строк кода. Покрытие кода не укажет вам на то, что вы что-то пропустили в исходном коде.

Покрытие всех путей выполнения функции тестами

Также вы можете накатить какие-то кастомные инструменты, как this article описывает. Если вы только формируете требования подход к тестированию, удобно настроить опциональную проверку и не останавливать билд. Так же в Azure DevOps есть возможность выдать права на изменение политики ветки определенным людям. Таким образом когда подход к тестированию, code coverage метрики и процент покрытия будет выработан, если есть потребность можно жестко регламентировать требования к покрытию тестами. Для упрощения примера и наглядности, будет протестирован только один из сервисов проекта, а в пайплайне используются прямые пути к файлам проекта, тогда как в реальных средах чаще используются переменные.

SHARE