Параллельные интеграционные тесты базы данных Postgresql в приложении GO

[@RPG18]

Для маленького проекта dockertest, что бы поднять из теста postgres и получить коннекшен; какой-нибудь migrate что бы накатить миграции.

[@r3code]

Поясните пожалуйста. Непонятно — это возражение или предложение.

[@RPG18]

Предложил другой способ, как можно делать то же самое.

[@r3code]

А подробнее? На что миграции накатываем? На пустую базу или на любую имеющуюся копию. Интересно расскажите подробнее.

[@RPG18]

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

[@r3code]

А есть пример проекта посмотреть как это в деле? Хочется знать ваш способ

[@david_mz]

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

[@r3code]

Таблицы не переименовываются. Создается временная схема, в ней создается нужная таблица. Соединение работает на указанной схеме. Т.е. каждый тест работает со своей схемой, потому можно хоть два теста на одной таблице запустить, например проверку вставки, List и удаление — они будет независимы по данным.

[@david_mz]

Это я понимаю, но автор руками в каждом запросе перед именем таблицы вставляет имя схемы. Регекспами. Это хрупко и неполно (как с функциями быть, например, они тоже в схемах определяются), но к тому же и не нужно — текущую схему можно задать через set search_path и дальше использовать немодифицированные запросы.

UPD: точнее, поскольку тут go, то использовать надо параметр search_path в connection string.

[@r3code]

А как бы сделали вы? Может у вас есть ссылка на метериал, как этого можно добиться иначе, или свой подход можете описать?

[@LeKovr]

А почему бы не выполнять каждый тест в своей транзакции? В этом случае
1. не надо менять имя схемы
2. можно гонять тесты и на боевой БД
3. можно гарантировать, что код в БД поменяется только при успешном прохождении тестов

[@r3code]

А теории да, а на практике что?

[@LeKovr]

На практике миграцию мы делаем так —
1. BEGIN;
2. Удалить схему со старым кодом
3. Создать схему с новым кодом
4. Прогнать тесты нового кода
5. При успехе — коммит

Правда, у нас параллельность не очень актуальна — 300+ тестов проходят за пару минут, делаем подряд

[@r3code]

Спасибо. Попробуем у себя и вашу схему.