TDD и покрытие тестами

Что покрытие измеряет на самом деле

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

Учёт ветвлений строже: он считает не строки, а переходы. Условие, которое всегда выполнялось только в одну сторону, считается покрытым по строкам и НЕ покрытым по ветвям. В моём замере это дало 64% против 62% и прямое указание на непроверенную ветку.

// Отсюда практика: включать учёт ветвлений всегда, а на само число смотреть не как на оценку, а как на карту. Полезно не «поднять с 64 до 80», а открыть отчёт и посмотреть, ЧТО именно не покрыто. Обычно там обнаруживается обработка ошибок - самая опасная часть кода, потому что выполняется она редко и именно в плохой момент.

покрытие строк

какие строки выполнились; о проверке результата ничего не говорит

покрытие ветвлений

какие переходы условий выполнились; строже и полезнее

Какой процент нужен

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

Работающий подход другой. Ставится порог, который сейчас достигнут, и запрещается его СНИЖАТЬ. Отдельно требуется покрытие для НОВОГО кода - обычно заметно выше общего. Так набор растёт естественно, а старый код чинится по мере того, как его трогают.

// И ещё одна практика, которая ценнее процентов: смотреть покрытие критичных модулей отдельно. Расчёт денег, права доступа, обработка платежей должны быть покрыты плотно, а вспомогательные скрипты - как получится. Средняя температура по больнице тут врёт особенно сильно.

порог без снижения

текущее покрытие фиксируется, падать ниже нельзя

покрытие нового кода

требование к изменению, а не ко всему проекту сразу

Разработка через тесты

Цикл простой: сначала пишется падающий тест, потом минимальный код, чтобы он прошёл, потом код приводится в порядок при зелёных тестах. Смысл не в самих тестах, а в двух побочных эффектах.

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

// Честно про границы: подход не универсален. Он плохо ложится на исследовательскую работу, где неизвестно, что должно получиться, и на задачи, где интерфейс диктуется снаружи. На собесе разумно так и сказать: применяю там, где поведение известно заранее, а не как религию.

цикл разработки через тесты

красный тест, минимальный код, приведение в порядок

проверенная способность краснеть

тест видели упавшим, значит, он действительно что-то проверяет

Как отвечать: «Какое покрытие считать достаточным?»

Я не считаю покрытие оценкой качества - это карта того, какой код выполнялся. Строка, которую вызвали и не сверили ни с чем, засчитывается покрытой, поэтому набор с высоким процентом и слабыми проверками ловит меньше, чем кажется. Поэтому первое, что делаю, - включаю учёт ветвлений вместо строк. Я мерил на маленьком примере: один тест на счастливый путь дал 64% по строкам и 62% по ветвям, и отчёт прямо показал непроверенную ветку обработки неверного ввода. Дальше вместо погони за числом смотрю, ЧТО не покрыто: обычно это обработка ошибок, самая опасная часть кода. А в конвейере ставлю не абсолютный порог, а два правила: не снижать текущее покрытие и требовать высокое покрытие для нового кода. Отдельно смотрю критичные модули - расчёт денег и права доступа - там нужна плотность, а не средняя температура по проекту.

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

На чём валятся

• −Считают высокое покрытие доказательством качества тестов.
• −Меряют покрытие строк вместо ветвлений и не видят непроверенных условий.
• −Гонятся за ста процентами и пишут бессмысленные тесты ради последних процентов.
• −Смотрят среднее по проекту и не видят дыры в критичных модулях.
• −Никогда не видели свой тест красным и не знают, работает ли он.