"Тестирование в эпоху AI агентов ч2/3 ... Теперь к некоторым техникам. Хочу поделится парой моментов. ‼️ Эфемерная БД: сейчас модно и молодежно использовать в проектах штуки типа Neon / Supabase. Это postgres но с сервисами. Гонять облачную БД для тестов - немного неспешно. Возможное решение: эфемерной локальная БД. Мы поднимаем локальную БД докером, делаем для нее volume в оперативной памяти, и гоняем тесты в этой базе. Почему такой термин - эфемерная? Потому что как только отключим том или гасим докер, то база просто пропадает. Для тестов - самое оно. Раз в 8-10 быстрее бегает, чем с облачной БД. Рекомендую. ‼️ World ID. Задача: для каждого теста хотим свой набор данных, чтобы реализовывать задуманный сценарий с детерминированным состоянием БД. Хотим чтобы тесты выполнялись параллельно. Как обеспечить? Предлагаю такое решение: небольшое ""Начало"" / мультиверс, а если без художественных аналогий, то ""мягкое шардирование"". Мы добавляем в каждую табличку БД поле world-id, идентификатор ""мира"". И индексы PK каждой таблички переделываем на использование world-id + id. Для чтения используем WHERE world-id = нужный нам мир. Суть в том, чтобы получить возможность параллельно хранить в БД разные наборы данных. Чтобы для каждого теста мочь быстро создать такой набор данных. 🟢 Плюсы такого подхода: - создать мир ничего не стоит - просто новый ключ для world-id. - нет заморочек с миграциями - используем одну БД; - нет проблем с коннектами; используем основной коннект; 🔴 Минусы: - в каждый запрос добавляем world-id; - я обычно добавляю такую штуку в слой доступа к данным (repository pattern), чтобы это было автоматом и прозрачно; тогда использовать очень просто; - можно использовать RLS (row level security) для автоматизации на уровне БД : - ALTER TABLE users ENABLE ROW LEVEL SECURITY; - CREATE POLICY isolate_worlds ON users USING (world_id = current_setting('app.current_world_id')::uuid); - SET app.current_world_id = 'uuid-вашего-мира'; - ключи обязательно включают world-id, но я использую UUID как ключи - поэтому все проще; - чистить БД чуть дольше, но эфемерную БД после тестов можно просто погасить, без очистки; ▶️ Альтернативные варианты: * делать отдельные БД для каждого теста: жирновато и медленно - делаем БД, накатываем схему, накатываем сид; просто чистить - дропаем базу; * делать отдельную схему для каждого теста - SCHEMAS (Namespaces); почти так же муторно как создавать БД, та же проблема с миграциями; зато для очистки простой DROP SCHEMA; * транзакции - сложность с кодом, который использует транзакции, потому что вложенные транзакции это немного больно и надо переходить на SAVEPOINTS (и переделать все хуки если они имеются - по мне так рефакторинг немаленький); мне не очень подходит чтобы переделывать транзакции; сложность с обработкой запросов в разных подключениях, например в интеграционных тестах апи; В общем, если важно быстро сделать новый мир - тогда world-id. В проде world-id всегда null. ..."