Какие проблемы возникают при использовании одних и тех же данных и пользователей в параллельных тестах

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

Умеете ли вы строить тестовые данные так, чтобы тесты не зависели от порядка и соседей. Вопрос обычно возникает, когда набор автотестов на Java переводят в параллельный режим и он начинает «мигать». Следом спрашивают, как вы изолируете данные и кто их чистит.

Как отвечать

Опишите конкретные эффекты общих данных:

• перетирание состояния: один тест меняет пользователю язык или адрес, другой в это время проверяет старое значение. Корзина, баланс, число заказов: любые проверки абсолютных значений начинают падать случайно;
• сессии: если система разрешает одну активную сессию, логин того же пользователя во втором потоке выбивает первый;
• блокировка аккаунта и лимиты: негативный тест с неверным паролем блокирует пользователя, на котором работают остальные;
• уникальные ограничения: два теста создают сущность с одинаковым именем, один падает на дубликате;
• очистка: @AfterEach удаляет данные, которые ещё нужны соседнему тесту.

Как решать:

• свои данные на тест: каждый тест создаёт пользователя и сущности через API или билдеры с уникальным суффиксом, например из UUID;
• пул учётных записей: если пользователей создавать нельзя, их выдают из очереди и возвращают после теста, и один аккаунт не попадёт в два потока;
• изоляция окружения: отдельная база на прогон через Testcontainers;
• управление параллельностью в JUnit 5: junit.jupiter.execution.parallel.enabled=true, а тесты на общий ресурс помечаются @ResourceLock или @Isolated;
• потокобезопасность самих тестов: WebDriver или клиент с токеном в статическом поле делится между потоками, храните такое в ThreadLocal или создавайте на тест.

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

Надеются на @Transactional с откатом. В тесте Spring с webEnvironment = RANDOM_PORT запрос обрабатывает сервер в другом потоке и другой транзакции, и откат теста его изменения не отменит.

Предлагают моки как решение. В интеграционных и end-to-end тестах общая база никуда не девается, моки убирают лишь часть проблемы.

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