Test data, mocks и service virtualization

Автотесты падают от нестабильных данных и зависимостей не меньше, чем от багов. Mocks и service virtualization помогают контролировать внешние сервисы, но их нужно использовать осознанно, чтобы не протестировать выдуманный продукт.

Что важно понять

Какие зависимости должны быть реальными, а какие можно заменить.
Данные, которые тест создаёт сам, и данные, которые берёт из fixture.
Контракт mock-сервиса и его соответствие реальному API.
Параллельность, cleanup, idempotency и уникальность тестовых сущностей.

Рабочий порядок

Определите внешние зависимости сценария.
Решите, где нужен real integration test, а где достаточно mock.
Версионируйте mock-контракты и проверяйте их против реального сервиса.
Сделайте данные одноразовыми и независимыми от порядка запуска.

Что отдавать команде

Data factory или fixtures.
Mock contracts.
Список real integration checks для контроля расхождений.

Частые провалы

Мокать всё и терять реальные интеграционные ошибки.
Использовать статичные аккаунты, которые ломают параллельность.
Не обновлять mock после изменения контракта.

Практика

Для платежного сценария решите, какие ответы провайдера мокать: success, decline, timeout, pending, duplicate. Затем оставьте один real sandbox flow.