Как устроено хранение данных в тестах?

Что проверяют

Понимаете ли вы, откуда тест берёт данные и почему он проходит одинаково на ноутбуке, в CI и на соседнем стенде. Следом обычно спрашивают, как вы готовите и чистите данные при параллельном запуске и где храните логины и пароли тестовых пользователей.

Как отвечать

Разложите ответ по видам данных:

• входные параметры проверок: для data-driven тестов их выносят в параметризацию (@pytest.mark.parametrize, @ParameterizedTest с @CsvSource в JUnit 5, @DataProvider в TestNG) или во внешние файлы JSON, YAML, CSV рядом с тестами в репозитории;
• сущности, которые нужны тесту: пользователь, заказ, товар. Надёжнее всего создавать их в setup через API или фабрику (factory_boy, паттерн Test Data Builder, генерация через Faker) и удалять в teardown. В pytest это фикстуры с yield и подходящим scope;
• база данных: сид через SQL-скрипты или миграции, откат транзакции после теста, одноразовая база в контейнере через Testcontainers;
• конфигурация окружения: адреса стендов и флаги лежат в конфиге или переменных окружения, чтобы один набор тестов шёл на разные стенды;
• секреты: пароли и токены в репозиторий не кладут, их берут из переменных CI или хранилища вроде Vault.

Главный принцип: каждый тест создаёт свои данные или получает их в известном состоянии и не зависит от порядка запуска. Уникальность дают префиксы и случайные суффиксы в именах, тогда параллельные потоки не мешают друг другу.

Если в тестовую среду копируют данные с прода, упомяните обезличивание: персональные данные нельзя переносить как есть, этого требуют и безопасность, и 152-ФЗ.

Где спотыкаются

Завязывают тесты на конкретный ID или пользователя, который существует только на одном стенде. На другом окружении всё падает без единого изменения в продукте.

Путают тестовые данные с моками и стабами. Моки подменяют зависимости, а вопрос про то, где лежат и откуда берутся сами данные.

Используют одного общего тестового пользователя на все параллельные тесты. Один тест меняет ему настройки, другой падает, и это выглядит как нестабильный тест, хотя виновата общая учётка.