Тестирование баз данных и событий

Многие дефекты не видны на UI сразу: данные сохранились частично, событие ушло дважды, миграция сломала старую запись, очередь обработалась с задержкой. QA должен уметь проверять не только экран, но и состояние системы после действия.

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

• CRUD-операции, транзакции, уникальность, индексы, soft delete.
• Миграции данных и совместимость старых записей с новым кодом.
• Очереди, события, retry, dead letter и идемпотентность обработчиков.
• Консистентность между сервисами и задержки eventual consistency.

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

1. Опишите, какие данные должны измениться после действия.
2. Проверьте запись через API, read model, админку или SQL, если доступно.
3. Отследите событие и повторную обработку при ошибке.
4. Проверьте откат или компенсацию при частичном сбое.

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

• Data assertions для сценария.
• Список событий и ожидаемых payload.
• Логи обработки и id сущностей для дефекта.

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

• Считать UI-успех доказательством сохранения данных.
• Не проверять повторную доставку события.
• Игнорировать старые данные после миграции схемы.

Практика

Проверьте создание заказа: запись в БД, событие OrderCreated, списание резерва товара, отсутствие дубля при повторном запросе.