не обязательно, может быть и одна

как настроишь

у них же 2 разных конфига

Я для приёмочных делал миграции из приложения и так получал исходную БД. А для интеграционных чтобы она очищалась, нужно дамп использовать выходит

я делал один дамп для всех тестов, пустой

каждый тест наполнял как ему нравилось

после каждого теста накатывался опять пустой дамп

И после каждой новой миграции - дамп обновлять?

да

Да, с таким подходом можно в одной БД

я не знаю как другие, я не то чтобы каждый день структуру бд менял)

по этому не напрягало

Спасибо! Буду дальше разбираться :)

Я перед тестами миграции накатываю, а тесты провожу внутри транзакций. Чутье подсказывает, что так можно напороться, но пока все хорошо)

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

На большом проекте это будет работать долго, конечно. В одной большой компании для ускорения таких кейсов сделали отдельное апи специально для тестов, которое, например, создаёт юзера и сразу возвращает его токен авторизации, а тесты экономят таким образом запрос. И часть бизнес-логики в таких эндпоинтах не используется (тоже для ускорения).
Конечно, тут тоже есть минусы вроде поддержки отдельного апи. Но это же - и способ тестирования всякой асинхронной логики (напр., в той же конторе есть эндпоинт, который не отдает ответ до тех пор, пока не пересчитается определенный индекс сфинкса).

Интересный подход) А в коде это как выглядит, в каждом тесте транзакция и ролбэк?

setUp/tearDown

Понял, спасибо :)

Могу скинуть класс который генерит тестовую базу. Берет схему с основной базы и накатывает в тестовую.