Сколько тестов нужно

Не «как можно больше» и не «для галочки», а ровно столько, сколько снимает риск.

Достаточность тестов определяется не числом и не процентом покрытия, а тем, покрыты ли важные и рискованные части системы значимыми проверками.

Не количество, а риск

Вопрос «сколько тестов» неправильно поставлен. Тысяча тестов на геттеры-сеттеры бесполезнее десяти на ядро бизнес-логики. Тесты — это управление риском, поэтому усилия направляют туда, где цена ошибки высока и вероятность ошибки выше.

Тестировать тщательноМожно скромнее
Деньги, оплаты, расчётыТривиальные геттеры
Авторизация, доступы, безопасностьОчевидный одностраничный код
Сложная логика с ветвлениямиПрототипы, которые скоро выкинут
Места частых багов в прошломСтабильный сторонний код

Признаки «тестов достаточно»

  • Все ветви ключевой логики покрыты осмысленными проверками.
  • Покрыты граничные и негативные сценарии, а не только «счастливый путь».
  • Каждый найденный в прошлом баг закрыт тестом (чтобы не вернулся).
  • Вы чувствуете уверенность, выпуская изменение, — тесты дают эту уверенность.

Пример: важная логика заслуживает многих сценариев

Расчёт цены с учётом скидки и налога — место, где ошибка стоит денег. Здесь оправдано несколько проверок: обычный случай, граница, негатив.

def final_price(price, discount_pct):
    if not 0 <= discount_pct <= 100:
        raise ValueError("Скидка должна быть от 0 до 100")
    discounted = price * (1 - discount_pct / 100)
    return round(discounted * 1.2, 2)   # +20% налог


# Несколько сценариев именно потому, что это важная денежная логика
assert final_price(100, 0) == 120.0      # без скидки
assert final_price(100, 50) == 60.0      # половинная скидка
assert final_price(100, 100) == 0.0      # граница: 100%
try:
    final_price(100, 150)                 # негатив: недопустимая скидка
    bad = False
except ValueError:
    bad = True
assert bad
print("Важная логика покрыта: обычный, граничный и негативный сценарии")

Вывод:

Важная логика покрыта: обычный, граничный и негативный сценарии

Закон убывающей отдачи

Первые тесты на критичный код дают огромную пользу. Сотый тест на тот же простой модуль — почти ноль. Останавливайтесь, когда добавление теста перестаёт реально снижать риск. Цель — уверенность при минимуме сопровождения, а не рекордный процент.

Итог

  • Достаточность измеряется снижением риска, а не числом тестов или процентом.
  • Тщательно тестируйте важное и опасное; тривиальное — скромно.
  • Действует закон убывающей отдачи: не гонитесь за идеальной цифрой.
Проверьте себя
1. Чем определяется, что тестов «достаточно»?
AЧислом тестов больше тысячи
BПокрытием важных и рискованных частей значимыми проверками
CРовно 100% покрытия
DКоличеством строк в тестах
2. Что стоит тестировать особенно тщательно?
AТривиальные геттеры и сеттеры
BДеньги, авторизацию, сложную логику и места прежних багов
CПрототипы, которые скоро выкинут
DСтабильный сторонний код
3. Что описывает закон убывающей отдачи в тестировании?
AКаждый новый тест полезнее предыдущего
BПервые тесты на критичный код дают огромную пользу, а лишние на простой модуль — почти ноль
CТесты всегда бесполезны
DЧем больше тестов, тем лучше всегда
Поддержать проект