Подружить CI, unit-тесты и базу данных

[tbl]

Для Oracle Database нет решения, позволяющего поднять локальную базу на том агенте, где гоняются юнит-тесты без всяких контейнеров? Просто для mysql и postgresql есть такие решения, подключаешь в виде библиотеки к проекту и все готово:
https://github.com/vorburger/MariaDB4j
https://github.com/opentable/otj-pg-embedded
https://github.com/yandex-qatools/postgresql-embedded

[tbl]

Кстати, нет смысла поднимать схему на каждый тест, достаточно поднять один раз при запуске юнит-тестов, а потом транкейтить таблицы между тестами. Если база для тестов поднята на диске, смапленном в память (tmpfs, например), то truncate table… cascade по всем таблицам выполняется моментально.

[kotbajan]

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

[kotbajan]

Я описывал решение проблемы, когда тесты запускаются на jenkins параллельно (проверяют pull-реквесты) и каждому нужна своя база.

[tbl]

Если это возможно, то проще не завязываться на внешний пул баз/схем, и, если для oracle не подходит embedded-решение, то да, приведенное в статье решение будет одним из оптимальных. Другой вариант — поднимать базу в контейнере: раз и два. Можно даже oradata копировать, чтобы каждый раз не инициализировать бд с нуля.

[kotbajan]

Embedded решений я ни 1 не видел. Есть H2 поддерживающая диалект оракла, но сильно не полноценно.

[alexprey]

Очень радует, что тестирование слоя взаимодействия с БД приобретает все большую популярность. Было дело и мы задались этим вопросом для связки C# + MySql. Но подход в инициализации данных использовали другой, хотелось обеспечить не только возможность параллельных сборок, но и параллельного запуска тестов. Да и кол-во схем баз данных, очень далеко не равно 1. Поэтому мы подошли к этому процессу несколько иначе. Можно тут почитать статью: https://habr.com/ru/company/arcadia/blog/304322/
Очень порадовал момент с тестированием апдейтов и роллбеков.
Интересует вопрос производительности еще

[kotbajan]

Запускать параллельно тесты в рамках одной сборки — потратить время на создание структуры через liquibase, это накладнее по производительности. Сейчас по производительности бьет халатное отношение к ней. Если мне надо протестировать запрос на 1000 записей, у меня будет 1000 операций вставки. Объединение в batch сократило воемя выполнения одного из таких тестов с 17 сек до 1. Так же с ростом changelog-а будет увеличиваться время первого наката структуры.

[tbl]

Тесты можно в батчи склеивать, которые уже гонять параллельно

[kotbajan]

В статье количество схем в пуле 10, без проблем сделать больше, просто этого хватает. В бою (не для статьи) используется не по 1 схеме на тест, а по несклько — в метаданных перечисляются схемы с разными префиксами, но одинаковыми id-суффиксами: Схема на заполнение БД и схема "пользователя без таблиц", куда только гранты на чтение выдаются.