если кратко: вместо подготовки данных в тесте
user = 'vasya',
в датапровайдере можно получать данные по запросу типа
User().isRegistered(True).hasFollowers(True).withReviews(True).getRandom()
вместо конкретного пользователя который подходит тестовым критериям в твоем тесте может быть логическая обвязка и билдер этих критериев. а затем рандомизация сущности, которая этим критериям подходит. Эта сущность может (и по-хорошему должна) исключаться для других тестов, чтобы тесты оставались independent & atomic, чтобы тесты можно было гонять в параллели,
Такой подход подразумевает, что в тестовом контуре есть достаточно данных для всех тест-кейсов в БД:, то есть слепок базы данных может быть прод-лайк или урезанный дамп с прода, а те сущности которых нет -- могут периодически по шедулеру миграциями накатываться на тестовую базу с разного рода "мутациями" полей и их значений, чтобы допустить, что в какой-то момент тест будет брать объект удовлетворяющей тестовой гипотезе, но содержащий какие-то рандомные данные якобы не влияющие на тест, Иногда выясняется, что либо гипотеза тестовых данных не верна. либо "неважные" данные оказываются важны,
так вот, с таким подходом формирования тестовых данных и изоляции, можно разграничить тесты на сравнительно быстрые рид-онли операции в базу перед непосредственно исполнением тестов, в то время как миграции накатываться будут для соблюдения полноты данных где-то раньше по графику.
Плюсы:
перед каждым тестом не нужно создавать исходные данные, вполне возможно они уже есть в базе (мы используем прод-лайк базу или урезанный дамп базы с полными консистентными связями таблиц) нужно просто их получить селектом (в примере 2fingers для это используется builder pattern и ORM)
Минусы:
база данных может быть не богата на данные для теста, конкретный инстанс бд может становиться пустым со временем -- если запускать на нем 100 раз подряд тесты на удаление объектов, например
Воркэраунд минуса:
-- для тестов в которых часто не хватает данных либо все еще использовать "конфиговые" значения, то бишь хардкод и создавать их на месте.,
-- придумать миграции похитрее, которые будут проходить в фоне и находить пустые таблички, докидывая в них данные для тестов
-- гонять тестовые наборы с +- одинаковым удалением / созданием / изменением на один тестовый запуск