Follow us on Twitter
    slavb18

    ИИ клянется, что код работает? Почему юнит-тесты с моками стали ментальной ловушкой в эпоху LLM

    AI DevelopmentLLMSoftware TestingUnit TestingIntegration TestingMocksCoding Best PracticesAI Assisted CodingProduction Readiness

    Your AI Swears the Code Works? Why Unit Tests with Mocks are a Mental Trap in the LLM Era

    Мы все там были. 🤯 Вы открываете Cursor или Claude Code, набрасываете задачу, нейросеть за секунду генерирует элегантный класс и вдогонку насыпает пачку юнит-тестов. Локальный запуск - всё зеленое. Вы со спокойной душой катите это в продакшен, и через пять минут Slack взрывается от алертов. 💥 Интеграция упала. Почему? Потому что модель была абсолютно уверена в своей правоте. Она создала идеальный код в вакууме.

    В 2026 году пора признать очевидное: эра «вайб-кодинга» и слепого доверия спецификациям ИИ подошла к концу. 🛑 Единственное, что отделяет ваш бизнес от катастрофы на проде - это жесткие, детерминированные интеграционные тесты. Без моков, без заглушек, без жалости.

    Иллюзия корректности: почему ИИ всегда будет врать

    Главная проблема современного софта, написанного с помощью ИИ, называется Intent Gap (разрыв между намерением и реализацией). 🤖 Код, сгенерированный большой языковой моделью, является правдоподобным по определению, но он не является корректным по определению.

    Когда вы просите модель проверить себя или написать юнит-тест, происходит следующее: 👇

    1. Модель берет за основу свое (возможно, ошибочное) представление о контексте.
    2. Генерирует код.
    3. Пишет юнит-тест, который тестирует этот же код в рамках той же самой логической ошибки.

    Нейросеть будет до последнего клясться, что код соответствует вашей спецификации. Она даже подберет цитаты из вашего ТЗ. Но ИИ оперирует вероятностями и статистической близостью слов, а не законами физики или строгой логикой рантайма.

    Ловушка юнит-тестов: тестирование собственных галлюцинаций

    Долгое время нас учили, что классическая пирамида тестирования - это база: много быстрых юнит-тестов в изоляции, чуть меньше интеграционных, и единицы сквозных (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).

    Заключение

    ИИ - это великолепный мультипликатор скорости, но ужасный гарант стабильности. 🚄 Он прекрасен на этапе создания «черновиков» кода, но абсолютно слеп к системным эффектам и граничным случаям интеграции.

    Перестаньте тратить время на полировку многостраничных спецификаций в надежде, что агент поймет их идеально. 🛑 Перестаньте плодить тысячи бесполезных юнит-тестов, которые проверяют работоспособность заглушек, написанных тем же ИИ.

    Пишите интеграционные тесты. ✅ Фиксируйте факты кодом. Если система выдерживает прогон через реальную инфраструктуру - значит, код готов. Всё остальное - просто вайб и маркетинг, которые рассыпаются при первом же запросе от реального пользователя.

    📚 Читайте также