Интеграционные тесты с базой

«Учебный заказ создаёт шапку и две позиции; у второй несуществующий product_id. После отказа в базе нет ни заказа, ни первой позиции». Попросите затем успешный сценарий с двумя допустимыми товарами. Проверяйте состояние независимым запросом, а не только вызов rollback. Важно доказать бизнес-результат реального SQL, включая ограничения схемы и поведение драйвера в выбранной СУБД.

Нет, если приложение использует другое соединение, проверяется commit или работают фоновые процессы. Внешняя транзакция может скрыть данные от второго участника и дать результат, не похожий на рабочий сценарий. Попросите сравнить откат, очистку таблиц и отдельную схему. Способ изоляции должен сохранять проверяемое поведение, а не только быстро возвращать базу к пустому состоянию после каждого теста.

Разделите пространство данных или базу для каждого исполнителя и задайте уникальные идентификаторы. Очистка общих таблиц одним тестом не должна удалять данные другого. Попросите сценарий двух одновременно создаваемых заказов и случайный порядок запуска. Контейнер сам по себе не обеспечивает независимость, если все тесты используют одну схему и одинаковые записи без согласованной стратегии очистки и подготовки.

Тест обнаруживает намеренное нарушение атомарности или ограничения, проходит на корректном коде и повторяется независимо от порядка. Сохраните логи реального отказа и очистки. Енотик подготавливает тестовый сценарий, но не поднимает вашу базу автоматически. Проверяйте переменные подключения особенно внимательно: интеграционный набор должен использовать выделенное тестовое хранилище, а не случайно обращаться к рабочим данным приложения при локальном запуске.