🛠 Шпаргалка: как писать тесты, которые не бесят

Главная проблема тестов — хрупкость. Это когда вы просто переименовали функцию или разбили один метод на два (не меняя логику), а тесты упали. Значит, вы тестировали детали реализации, а не поведение.

Solitary (Одиночные): Изолируем юнит, заменяя всё вокруг моками.

❌ Минус: Тест намертво привязан к структуре кода. Изменили вызов — тест упал.
✅ Когда юзать: Только для экстремально сложных алгоритмов с кучей граничных кейсов.

Sociable (Общительные): Тестируем юнит вместе с его реальными зависимостями (если они не лезут в БД/сеть).

✅ Плюс: Высокая устойчивость к рефакторингу. Код внутри меняется — тест остается зеленым.
💡 Правило: Тестируй «что» делает код (результат), а не «как» (какие методы дергает).

Что и чем тестировать:
— Бизнес-логика (условия, расчеты, правила): Sociable Unit (минимум моков).
— Координация (код, который дергает БД, шлет письма, вызывает API): Интеграционный / Сервисный тест.
— Тривиальный код (простые геттеры, проброс параметров): Не тестировать отдельно. Он автоматически покроется интеграционными тестами.

Три правила «здорового» теста:
— Защита от багов: Находит ли тест реальную ошибку в логике?
— Устойчивость к рефакторингу: Могу ли я переписать код с нуля, сохранив результат, чтобы тест не упал?
— Простота поддержки: Насколько легко понять, что сломалось, без дебаггера?

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст