Stub возвращает подготовленные ответы, помогая задать условия теста. Fake содержит работающую, но упрощенную реализацию зависимости, например хранилище в памяти. Mock используют для проверки ожидаемых взаимодействий: вызовов, аргументов или количества обращений. Один инструмент может поддерживать несколько ролей, поэтому важнее способ использования, чем название класса.
В чем разница между стабами, фейками и моками?
Чем различаются роли тестовых двойников: заданные ответы стаба, упрощенная реализация фейка и проверка взаимодействий с моком.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Все три понятия относятся к тестовым двойникам: заменам зависимостей, которые помогают управлять условиями теста. Различать их удобнее по роли в проверке, а не по библиотеке, которой они созданы.
Stub, или стаб, предоставляет заранее заданные ответы. Например, вместо внешнего сервиса курса валют возвращает фиксированный курс, чтобы проверить расчет итоговой суммы. Главный вопрос теста — правильно ли сработал проверяемый код при заданных условиях, а не сколько раз вызвали стаб.
Fake, или фейк, содержит работающую, но упрощенную реализацию. Например, репозиторий сохраняет и читает записи из памяти вместо реальной базы данных. Он поддерживает необходимое поведение, однако может не повторять транзакции, ограничения и особенности настоящего хранилища. Поэтому успешный тест с фейком не заменяет проверку интеграции с реальной зависимостью.
Mock, или мок, используют для проверки взаимодействий: был ли вызван определенный метод, с какими аргументами, сколько раз или в каком порядке. Например, после подтверждения заказа проверяют, что компонент отправки уведомлений получил нужного адресата и данные. Реальное письмо при этом отправлять не требуется.
Терминология библиотек может отличаться. Объект, созданный функцией с названием mock, может играть роль стаба, если его используют только для заданного ответа. Проверка вызовов после выполнения также пересекается с понятием spy.
Выбирайте минимально необходимый двойник. Избыточные проверки внутренних вызовов делают тесты чувствительными к рефакторингу, даже когда внешнее поведение не изменилось. Для каждого двойника полезно понимать, какие свойства реальной зависимости он намеренно не моделирует.