Используются ли стабы или моки на тестовом окружении
Что проверяют
Различаете ли вы заглушки в модульных тестах разработчика и заглушки внешних систем на тестовом стенде, и понимаете ли, что именно они скрывают. Следом обычно спрашивают, как вы убеждаетесь, что заглушка не врёт относительно настоящего сервиса.
Как отвечать
Начните с терминов, коротко и без академичности:
- стаб: отдаёт заранее заданный ответ. Проверяется результат работы тестируемой системы, стаб просто кормит её данными;
- мок: кроме ответа запоминает вызовы, и тест проверяет, что к нему обратились нужное число раз с нужными параметрами;
- фейк: упрощённая рабочая реализация, например база в памяти или локальное S3-хранилище на MinIO.
Дальше главное для QA: на стенде обычно заменяют не классы, а целые внешние сервисы. Платёжный шлюз, СМС-провайдер, партнёрские API, которые платные, нестабильные или не умеют отдавать нужные состояния. Инструменты: WireMock, MockServer, Mountebank, у многих платёжных систем есть своя песочница. Так воспроизводят то, чего от живого сервиса не добиться: таймаут, ответ 500, отказ банка, пустой список.
Сильный ответ называет границу. Стенд с заглушками нужен для функциональных и регрессионных проверок, но перед релизом должен быть прогон с настоящими интеграциями или хотя бы контрактные тесты (Pact, сверка с OpenAPI-схемой), иначе заглушка тихо расходится с реальным API. Если на вашем проекте заглушек не было, так и скажите и объясните, где бы они сэкономили время.
Где спотыкаются
Путают стаб и мок или говорят, что это одно и то же. Разница в том, что проверяется: состояние или взаимодействие.
Считают, что зелёные тесты на заглушках доказывают работоспособность интеграции. Они доказывают только то, что система правильно реагирует на ответ, который вы сами придумали.
Не следят за актуальностью: партнёр поменял формат поля, стенд зелёный, прод падает. Заглушки обновляют вместе с контрактом и хранят в репозитории, а не в чьей-то локальной настройке.