Как бороться с покрытием кода?

Question

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

• Используете ли вы покрытие кода в своих проектах, и если да, то почему?
• Является ли покрытие кода фиксированной частью ваших сборок или непрерывной интеграции? или вы просто используете его время от времени?
• Как вы справляетесь с числами, полученными из отчетов?

Answer 1

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

Мы не запускаем его каждую сборку, потому что я не знаю, чтобы мы анализировали его достаточно регулярно, чтобы это оправдать.

Мы анализируем отчеты для больших блоков unhit кода. Мы обнаружили, что это наиболее эффективное использование. В прошлом мы пытались достичь определенной цели покрытия кода, но через некоторое время отдача стала очень уменьшаться. Вместо этого лучше использовать покрытие кода как инструмент, чтобы убедиться, что вы ничего не забыли.

Answer 2

1) Да, мы используем покрытие кода

2) Да, это часть сборки CI (почему бы и нет?)

3) Важная часть - мы не ищем 100% покрытия. То, что мы ищем, это глючный / сложный код, который легко найти из ваших модульных тестов, и разработчики / лидеры будут знать тонкие части системы. Мы следим за тем, чтобы охват таких областей кода был хорошим и увеличивался со временем, а не уменьшался, поскольку люди взламывали больше исправлений без необходимых тестов.

Answer 3

Чтобы взглянуть на покрытие кода, нужно посмотреть, сколько НЕ покрыто, и выяснить, почему оно не покрыто. Покрытие кода просто говорит нам о том, что строки кода попали во время выполнения модульных тестов. Это не говорит нам, что код работает правильно или нет. Покрытие кода 100% - это хорошее число, но в средних и крупных проектах его очень трудно достичь.

Answer 4

Покрытие кода говорит вам, насколько велика ваша «ловушка для ошибок», но не говорит, насколько велики дыры в вашей сети.

Используйте его как индикатор для оценки ваших усилий по тестированию, но не как абсолютный показатель.

Можно написать код, который обеспечит вам 100% покрытие и ничего не тестирует.

Answer 5

Мы делаем это в сборке и видим, что она не должна опускаться ниже некоторого значения, например 85%. Я также делаю автоматические Top 10 крупнейших не покрытых методов, чтобы знать, с чего начать покрытие.

Answer 6

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

Посмотрите на этот образец Clover Панель управления для похожих идей.

Answer 7

1) Да, мы измеряем покрытие простого узла, потому что:

• это легко сделать с нашим текущим проектом * (веб-приложение Rails)
• это побуждает наших разработчиков писать тесты (некоторые приходят из фонов, где тестирование было специальным)

2) Покрытие кода является частью нашего процесса непрерывной интеграции.

3) Числа из отчетов используются для:

• обеспечить минимальный уровень покрытия (95% в противном случае сборка не удалась)
• найти разделы кода, которые должны быть проверены

В некоторых частях системы тестирование не так уж и полезно (обычно, когда вам нужно использовать фиктивные объекты для работы с внешними системами). Но, как правило, хорошее покрытие облегчает поддержание проекта. Известно, что исправления или новые функции не нарушают существующую функциональность.

* Сведения о настройке необходимого покрытия для Rails: Минимальный лимит 95 Впереди

Answer 8

Я считаю, что это зависит от самого кода. Я не буду повторять заявления Джоэла из SO подкаста № 38, но в итоге получилось «постараться быть прагматичным».

Большой охват кода в основных элементах приложения.

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

Когда речь идет о стволах или ветви кода, да, охват кода функциональностью (в отличие от каждой функции), очень важен.

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

Неизбежно, из-за изменения правительственного акта, мы должны были добавить параметр в уравнения, и все 100+ тестов прервались.

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

Answer 9

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

1. отчет о покрытии
2. покрытие филиала
3. MC / DC покрытие

Мы ожидаем достижения + 90% отчетности и покрытия филиалов. Покрытие MC / DC, с другой стороны, дает более широкий смысл для команды тестирования. Для непокрытого кода, мы ожидаем, что записи обоснования, кстати.

Answer 10

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

Так как у нас также есть полный набор тестов селен-сети, которые проходят через весь стек, мы также делаем дополнительную уловку:

Мы настроили веб-приложение с запущенным покрытием. Затем мы запускаем полностью автоматизированную тестовую батарею тестов селена. Некоторые из них являются только тестами на дым.

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

На самом деле у нас нет фиксированных показателей того, как часто мы делаем это, но все настроено на нажатие или две.