Левани перешел в новую команду, где метрика покрытия тестами была священной.
CTO требовал минимум 90% coverage для любого Pull Request. Левани решил перевыполнить план и добиться 100% на своем модуле управления инвентарем.
Первый месяц: погоня за цифрами
Левани писал тесты для каждой строчки кода.
Геттеры, сеттеры, вспомогательные функции форматирования — все получило свои тесты. Через четыре недели инструмент coverage показывал заветные 100%.
| Метрика | Показатель Левани | Средний по команде |
| Покрытие строк | 100% | 87% |
| Покрытие ветвлений | 98% | 76% |
| Время прогона тестов | 4 минуты | 45 секунд |
| Количество тестов | 312 | 140 |
CTO похвалил на планерке. Левани чувствовал себя образцовым разработчиком.
Инцидент на второй месяц
Пользователь сообщил о критической ошибке: при добавлении товара с отрицательным количеством система падала.
Как это возможно при 100% покрытии?
Левани открыл свои тесты и увидел проблему. Он проверял, что функция addInventoryItem вызывается и возвращает объект. Но не проверял, что происходит при некорректных данных.
Тест выполнялся, строка кода считалась покрытой. Но смысловая проверка отсутствовала.
Переосмысление подхода
Сеньор Бесо провел код-ревью всех 312 тестов Левани.
Вердикт: 180 тестов проверяют очевидные вещи и не дают реальной ценности. Вот сравнение до и после рефакторинга:
| Аспект | До (100% coverage) | После (85% coverage) |
| Полезных тестов | 132 | 94 |
| Формальных тестов | 180 | 0 |
| Найденных багов | 3 за месяц | 18 за месяц |
| Время поддержки | 8 часов в неделю | 2 часа в неделю |
Что изменил Левани
Он перестал гнаться за процентами и сфокусировался на критических сценариях.
- Удалил тесты простых геттеров — они не ломаются сами по себе
- Сосредоточился на граничных условиях — нулевые значения, пустые массивы, некорректный ввод
- Добавил тесты на бизнес-логику — именно там прячутся дорогие ошибки
- Перестал тестировать код сторонних библиотек — разработчики lodash уже это сделали
Покрытие упало до 85%, но качество выросло.
Реальный кейс через три месяца
Левани работал над модулем скидок.
Вместо слепого покрытия всех строк он составил список критических сценариев: скидка больше 100%, отрицательная цена, конфликт нескольких акций, истекший промокод.
Написал 47 тестов. Покрытие показало 79%. Зато за два месяца работы модуля — ноль багов от пользователей.
Левани понял: coverage измеряет, какой код выполнился, но не проверяет, правильно ли он работает
Теперь в команде новое правило: метрика покрытия — ориентир, но не цель. Главный показатель — количество критических сценариев, покрытых осмысленными тестами.