Ну вот пример, где не харкод

если они всегда будут писать Вася Пупкин в кач-ве юзера, то да, хардкод

если у тебя на любую сущность есть рандомизатор, который не мешает тестовой гипотезе ( не релевантен в текущем тесте), тогда нет, не хардкод

Пытаться в тестовых данных предусмотреть какие ещё возможны данные и делать сложную генерацию - вот это уже антипаттерн

Попытаться изолировать данные простым способом - окей, но не всегда это сработает

Изолируй без очистки два теста:
1. Авторизация когда нет ни одного юзера в базе
2. Авторизация когда есть юзер

define "сложная генерация"?
предусматривать что? обычно через орм можно попросить настолько абстрактные тестовые данные, насколько они нужны, им не обязательно быть детальными, те атрибуты котоыре не уточнены, будут просто рандомными

"нет ни одного юзера в базе" - прям вообще ни одного? или нет "такого же юзера в базе"?

Для разъяснения: когда вообще нет юзеров может быть запущен мастер первоначальной настройки с предложением создать первого админа

Просто первое что в голову пришло из простых кейсов

ну ок, для этого теста очевидно база нужна пустая, и для каких-то проектов которые работают с локальными клиентскими базами это актуально

в общем если подытожить я бы так сформулировал:

1) если накладно удалять данные часто, делай удаление реже (в конце тестов)
2) если нельзя делать один раз, потому что между тестами есть общее состояние / не могут работать параллельно, вводи изоляцию не через чистку базы, а через уникальные тестовые данные, изолированные в рамках нужных тебе сущностей
3) если все же принято решение чистки базы и это долго, возможно чистить ее можно менее аккуратно, например через truncate и без сохранения бинлога базы

Ещё не предлагали запускать тесты на in-memory storage? Каждая ORM имеет такой адаптер, пробросить его в тестовом окружении место вашей реляционной базки не составит труда. По завершении тестов она сама вайпнется.

Как сделать in-memory storage для постгреса?

Неверная интерпретация идеи. Адаптер сделать нужно не для постгреса, а вместо. Адаптеры к разным БД в ORM обычно имеют один интерфейс на инфраструктурном уровне, и должны быть взаимазаменяемы. Тестам должно быть всё равно, куда они данные складывают, если у них одинаково отрабатывают методы репозитория, условные save() и get_by_id().

Пример проекта (UI + API) + Allure + CI
https://habr.com/ru/post/513432/

Добавил в пин

Допустим у меня есть около 70 разных таблиц и с каждой я хочу прогнать тест, а тестов таких несколько. Лучшей практикой будет заряжать их в parametrize и получить в итоге over9999+ тест кейсов или в коде теста циклом проходить по всем и получить один тест?

Они же разные, значит и тесты будут разные

Спасибо,  тоже к этому склоняюсь

Эм. В вопросе у тебя были одинаковые