Тестирование в эпоху 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.

...