Как ты тестируешь код перед отправкой в production?
Ниже — вариант ответа, который показывает системный подход к качеству. Конкретный набор проверок зависит от продукта, рисков и процесса команды.
- Локально запускаю быстрые проверки: линтеры, статический анализ и unit-тесты.
- После отправки изменений CI повторяет проверки в чистом окружении и запускает более широкие наборы тестов.
- На тестовом стенде запускаются интеграционные, end-to-end и регрессионные сценарии. Эти понятия пересекаются, но не являются синонимами: end-to-end описывает охват системы целиком, а регрессионное тестирование проверяет, что уже работающий функционал не сломался.
- Если процесс команды это предусматривает, QA выполняет исследовательское и ручное тестирование.
- После развёртывания запускаются smoke-тесты и проверяются метрики, логи и алерты.
Unit-тесты
Unit-тест проверяет небольшую единицу поведения в изоляции и должен выполняться быстро и детерминированно.
- Модели и функции: проверяем значимые ветки, граничные значения, ошибки и бизнес-инварианты.
- Сервисный слой: внешние зависимости передаём явно и при необходимости заменяем тестовыми реализациями или mock-объектами.
- Валидация: отдельно проверяем собственные валидаторы и важные контракты. Повторно тестировать стандартное поведение Pydantic обычно не требуется.
- Побочные эффекты: события, логи и создание связанных сущностей проверяем только тогда, когда они являются частью наблюдаемого контракта.
Тест, который обращается к настоящей БД, очереди или файловой системе, обычно уже относится к интеграционным, даже если запускается рядом с unit-тестами.
Интеграционные тесты
Они проверяют взаимодействие нескольких реальных компонентов: например, репозитория с PostgreSQL, обработчика с брокером сообщений или FastAPI-приложения с тестовой БД. Здесь особенно важны управляемые фикстуры, изоляция данных и воспроизводимое окружение.
Тесты HTTP API
На границе API полезно проверять:
- статус-коды и формат ответа;
- входную валидацию и модель ошибок;
- authentication и authorization;
- сохранение данных и другие значимые эффекты;
- поведение при недоступности зависимостей.
Если внутренние зависимости полностью заменены mock-объектами, такой тест проверяет преимущественно контракт HTTP-слоя. Если приложение работает с реальной тестовой БД и несколькими слоями, это интеграционный тест.
End-to-end и регрессионные тесты
End-to-end-тест проходит пользовательский или бизнес-сценарий через всю систему. Например: создать пользователя, собрать корзину, оформить и оплатить заказ. Такие тесты дают высокую уверенность, но обычно медленнее и дороже в поддержке, поэтому ими покрывают ключевые сценарии, а не каждую комбинацию входных данных.