ИИ клянется, что код работает? Почему юнит-тесты с моками стали ментальной ловушкой в эпоху LLM
Код, сгенерированный ИИ, часто успешно проходит юнит-тесты, но спотыкается в продакшене. В этой статье мы разберем, почему слепая вера в модульные тесты с моками — особенно когда их пишут сами LLM — это ментальная ловушка, которая приводит к «разрыву намерений» (Intent Gap) и ложному чувству уверенности. Узнайте, почему в эпоху AI-assisted разработки критически важно переходить на детерминированные интеграционные тесты.
Авторы: slavb18
Мы все там были. 🤯 Вы открываете Cursor или Claude Code, набрасываете задачу, нейросеть за секунду генерирует элегантный класс и вдогонку насыпает пачку юнит-тестов. Локальный запуск - всё зеленое. Вы со спокойной душой катите это в продакшен, и через пять минут Slack взрывается от алертов. 💥 Интеграция упала. Почему? Потому что модель была абсолютно уверена в своей правоте. Она создала идеальный код в вакууме.
В 2026 году пора признать очевидное: эра «вайб-кодинга» и слепого доверия спецификациям ИИ подошла к концу. 🛑 Единственное, что отделяет ваш бизнес от катастрофы на проде - это жесткие, детерминированные интеграционные тесты. Без моков, без заглушек, без жалости.
Иллюзия корректности: почему ИИ всегда будет врать
Главная проблема современного софта, написанного с помощью ИИ, называется Intent Gap (разрыв между намерением и реализацией). 🤖 Код, сгенерированный большой языковой моделью, является правдоподобным по определению, но он не является корректным по определению.
Когда вы просите модель проверить себя или написать юнит-тест, происходит следующее: 👇
- Модель берет за основу свое (возможно, ошибочное) представление о контексте.
- Генерирует код.
- Пишет юнит-тест, который тестирует этот же код в рамках той же самой логической ошибки.
Нейросеть будет до последнего клясться, что код соответствует вашей спецификации. Она даже подберет цитаты из вашего ТЗ. Но ИИ оперирует вероятностями и статистической близостью слов, а не законами физики или строгой логикой рантайма.
Ловушка юнит-тестов: тестирование собственных галлюцинаций
Долгое время нас учили, что классическая пирамида тестирования - это база: много быстрых юнит-тестов в изоляции, чуть меньше интеграционных, и единицы сквозных (E2E). 🧪 В эпоху, когда код пишут люди, это работало. В эпоху ИИ эта схема превратилась в карго-культ.
Что такое юнит-тест с заглушками (моками)? Это проверка кода против вашего предположения о том, как ведет себя внешняя среда. 🤔
# Типичный юнит-тест, сгенерированный ИИ
def test_payment_processing(mock_stripe_api):
# Мы сами заставили мок вернуть True
mock_stripe_api.charge.return_value = {"status": "succeeded"}
result = process_order(order_id=123)
assert result.is_paid == True
Если ИИ неправильно понял формат ответа реального Stripe API или не учел, что при определенном типе ошибки сеть выплевывает 422 Unprocessable Entity вместо 400 Bad Request, ваш юнит-тест всё равно пройдет! ⚠️ Мок услужливо вернет то, что в него заложили.
В итоге вы получаете двойную галлюцинацию: ИИ написал код с ошибкой в интеграции и закрепил эту ошибку в моке. Тесты зеленые, разработчик счастлив, бизнес теряет деньги. 💸 Тестирование заглушек сегодня - это просто проверка того, насколько хорошо ИИ умеет подыгрывать самому себе.
Не доверяйте вероятности. Доверяйте фактам
Как разорвать этот порочный круг? Перевернуть пирамиду тестирования и сместить фокус на факты. 💡
📝 Спецификация (проза, промпт, ТЗ) - это вероятность. Это лишь предсказание того, как модель поймет вашу мысль в конкретный момент времени при определенной температуре. Завтра модель обновится до условной Claude 4.5 или GPT-5, и тот же самый текст будет интерпретирован иначе.
✅ Исполняемый интеграционный тест - это факт. Это детерминированный вердикт. Он не проходит через интерпретацию нейросетью. Ему плевать на «настроение» модели и контекстное окно. Он выполняется в реальном рантайме (Node.js, Python, JVM) и возвращает либо Exit Code 0 (успех), либо Non-zero (падение).
Единственная метрика работоспособности вашего приложения - это то, как оно ведет себя в реальной грязи: с настоящей базой данных, с настоящими сетевыми задержками и реальными сторонними API. 🛠️
Как должен выглядеть Facts-First подход в разработке
Если вы хотите, чтобы ИИ-ассистенты ускоряли вас, а не создавали скрытый технический долг, правила игры нужно менять прямо сейчас: 🚀
🚫 Убейте моки для внутренних сервисов. Поднимайте окружение в Docker-контейнерах (привет, Testcontainers). Если ваш код работает с PostgreSQL и Redis - тест должен писать в реальный Postgres и читать из реального Redis.
🤝 Используйте контрактное тестирование (Contract Testing) для API. Вместо того чтобы мокать ответы соседней команды или внешнего шлюза, внедряйте инструменты вроде Pact. Контракт должен проверяться на соответствие реальному поведению провайдера.
🎲 Внедряйте свойства и инварианты (Property-Based Testing). Вместо подбора трех банальных тест-кейсов, заставьте систему гонять через интеграционные шлюзы сотни случайных, но валидных комбинаций данных (например, с помощью Hypothesis).
Заключение
ИИ - это великолепный мультипликатор скорости, но ужасный гарант стабильности. 🚄 Он прекрасен на этапе создания «черновиков» кода, но абсолютно слеп к системным эффектам и граничным случаям интеграции.
Перестаньте тратить время на полировку многостраничных спецификаций в надежде, что агент поймет их идеально. 🛑 Перестаньте плодить тысячи бесполезных юнит-тестов, которые проверяют работоспособность заглушек, написанных тем же ИИ.
Пишите интеграционные тесты. ✅ Фиксируйте факты кодом. Если система выдерживает прогон через реальную инфраструктуру - значит, код готов. Всё остальное - просто вайб и маркетинг, которые рассыпаются при первом же запросе от реального пользователя.