Интеграционный тест создаёт заказ прямой записью в базу, минуя API, и затем успешно проверяет его отмену. Какой риск создаёт такая подготовка данных?
Такая подготовка может создать состояние, которое невозможно получить через реальный API. Тест проверит отмену искусственно созданного заказа, но не обнаружит ошибки в создании заказа, связанных проверках, обязательных побочных действиях или согласованности данных.
Прямую запись в базу допустимо использовать для ускоренной подготовки сложного состояния, но критические сценарии должны иметь отдельные проверки, где данные создаются через публичный интерфейс системы.
Интеграционные тесты появились как способ проверять взаимодействие компонентов на реальных границах: через HTTP, базы данных, очереди и внешние сервисы. Одной из исходных проблем были тесты отдельных модулей, которые проходили успешно, хотя компоненты не могли корректно обмениваться данными.
Для ускорения таких тестов начали применять фикстуры и прямую загрузку данных в хранилище. Это сокращает время подготовки, но одновременно обходит часть бизнес-логики, поэтому способ создания данных становится существенным свойством самого теста.
Заказ, записанный непосредственно в базу, может не иметь обязательного события, корректного статуса, связанной записи или результата проверки лимитов. С точки зрения схемы базы он может быть допустимым, но с точки зрения бизнес-процесса — недостижимым.
В результате тест отмены проверяет лишь реакцию системы на уже существующую строку. Он может пройти даже при сломанном API создания заказа или при отсутствии действий, которые обычно выполняются перед отменой. Такой тест создаёт ложную уверенность в корректности интеграции.
Сначала нужно определить, что именно проверяет тест. Если его цель — проверить отмену уже валидного заказа, данные можно подготовить напрямую, но фикстура обязана воспроизводить все существенные предусловия: допустимый статус, связи, обязательные атрибуты и версии данных.
Если цель включает сценарий создания заказа или совместную работу компонентов, заказ следует создавать через публичный API либо через тот же входной канал, который используется в эксплуатации. Это позволяет проверить валидацию, преобразование формата, транзакционные действия и публикацию связанных событий.
Практичный компромисс — разделить подготовку данных на два уровня:
Прямое обращение к базе не должно случайно заменять проверяемую границу. Кроме того, фикстуры нужно поддерживать при изменении схемы и бизнес-правил; иначе они начнут создавать устаревшие или недостижимые состояния.
Команда проверяла отмену заказа, вставляя в базу заказ со статусом «создан». Тесты проходили, но после изменения API выяснилось, что новые заказы стали получать обязательную запись аудита, без которой отмена в рабочем процессе должна была отклоняться.
Рассматривались два варианта. Полностью создавать каждый заказ через API обеспечивало реалистичность, но заметно увеличивало время набора тестов и количество зависимостей. Полностью сохранять прямую загрузку было быстрее, однако оно продолжало скрывать ошибки процесса создания.
Выбрали смешанный подход: большинство тестов отмены использовало проверенную фабрику данных, а отдельный интеграционный сценарий создавал заказ через API и затем отменял его. Фабрика дополнительно проверяла обязательные связи и статус. В итоге быстрые тесты сохранились, а нарушение предусловий создания стало обнаруживаться отдельной проверкой.
Нет. Оно оправдано, когда тестируемая операция начинается с уже существующего состояния, а создание этого состояния не входит в проверяемый сценарий. Ошибка возникает тогда, когда прямой способ подготовки обходит именно ту бизнес-границу, которую тест должен подтвердить.
Схема обычно гарантирует техническую целостность: типы, обязательность отдельных полей и связи. Бизнес-правила могут включать допустимые переходы статусов, наличие аудита, публикацию событий, лимиты и права доступа. Эти свойства не обязательно выражены ограничениями базы и потому требуют прохождения реального интерфейса или отдельной проверки.
Нужно периодически создавать аналогичную сущность через публичный интерфейс и сравнивать не только основные поля, но и связанные записи, статусы, события и побочные эффекты. Если прямые данные отличаются от результата штатного сценария, фикстура должна либо быть дополнена, либо применяться только в тестах, где эти различия намеренны.