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