Переход на embedded PostgreSQL в unit-тестах

[Borz]

используя Embedded PostgreSQL server, surefire пробовали использовать PostgresEmbeddedService?

[kullfar]

так в первых абзацах про сравнение yandex-qatools и otj-pg-embedded написано.

[Borz]

из того абзаца по пунктам.
1) то же самое можно сделать и в yandex-qatools, хотя да, "из коробки" это сразу не работает
2) версия подменяется при создании экземпляра класса EmbeddedPostgres, о чём в README.md в секции "How to use your custom version of PostgreSQL" написано
3) в qatools пока больших лагов в общении не заметил
4) для "разобраться" в кишках в том, как работает qatools чтобы сделать парочку исправлений мне хватило пары. дней. Для базовых настроек даже не помню сколько потратил времени, но очень мало
5) про логирование в том же README.md написано, а про "запуск одной строкой" — тоже вроде как работает "из коробки" — EmbeddedPostgres().start(_набор_параметров_длязапуска)

[kullfar]

Автор забыл про ещё один очень приятный бонус у otj-pg-embedded против yandex-qatools.
У otj-pg-embedded постгрес идет внутри джарки, а у яндекса при запуске тестов постгрес качается с интернета.
Если в компании такая ситуация, что есть много разработчиков и, главное, автоматизированных стендов, всяких CI и аналогичных, которые на чистой среде постоянно запускают сборку, то внешнему интернет-каналу быстро станет грустно и время сборки сильно увеличится на ожидание скачивания постгреса с сети, дополнительно добавляя новую точку отказа для сборки новой ветки. Нужно будет думать о кешировании-проксировании. А в случае с otj-pg-embedded, все быстро решается проксирующим мавен-репозиторием, который, как мне кажется, стоит в большинстве компаний с собстенной разработкой на java.

[Borz]

говорят, что если в ~/.embedpostgresql подсунуть нужный архив, то из интернета ничего скачиваться не будет.

А ещё можно при запуске передать runtimeConfig, в котором переопределить под свои потребности PostgresDownloadConfigBuilder и указать свой источник дистрибутивов

[Borz]

да, ещё про кеширование. в том же README.md есть секция "Known issues" — там как раз пример с использованием кеша

[kullfar]

Выглядит, что такое сложнее настроить. Придется на каждом «голом» образе, где планируется сборка ветки, предсоздавать директорию с постгресом и именно тем, что нужен для конкретной ветки.

[Borz]

эм. а как доставка в образ дистрибутива происходит в otj-pg-embedded? разве не так же?
т.е. есть "голый" образ, в который доставляется архив дистрибутива сервера, либо есть "неголый" образ с уже залитым дистрибутивом

[kullfar]

ну грубо говоря, CI видит новый коммит-ветку, берёт голый образ/виртуалку/chroot. в нём
1.git clone…
2.cd…
3.mvn clean install

[Borz]

повторю вопрос — откуда otj-pg-embedded в этом образе получает дистрибутив PostgreSQL? и как выглядит у вас запуск сервера БД? не "EmbeddedPostgresRules.singleInstance();" же используете?

[kullfar]

внутри мавен-артифакта лежит. т.е. из класспаса получает.

А запуск сервера БД идет в коде тестового класса:
final EmbeddedPostgres pg = EmbeddedPostgres.builder().start();
jdbcUrl = pg.getJdbcUrl(PG_USERNAME, PG_PASSWORD);

и дальше этот jdbcUrl используется для создания датасурсов всевозможных

[Borz]

ну, т.е. по сути, вы всё равно делаете доставку артефакта дистрибутива сервера в образ, просто средствами Maven.

[kullfar]

да. именно так и написал в первом комментарии. и кешируется внутри локальной сети средствами локально запущенного мавен-репозитария (на 99% уже установленного).

[kemenov]

А есть возможность подключать extensions например postgis, и как много с этим проблем?

[deebun]

В данный момент такой возможности нет, но в проекте otj-pg-embedded на github этот вопрос уже поднимался (в том числе, каким образом это можно было бы реализовать)

[kullfar]

ну вообще, в opentable можно подсунуть свой архив с постгрес. не совсем тривиально, но вполне реально, с яндексом проблематичнее вышло. У яндекса только выбрать из их predefined набора версий можно. Что-то кастомное выглядит сложнее, чем в opentable подсунуть.

[Borz]

а разве postgres.start(cachedRuntimeConfig("/path/to/my/extracted/postgres")); это не то самое "кастомное"?

[kullfar]

Ну опять же — думать про доставку в среду.
и даже без CI.
Пришёл новый разработчик в компанию. И вместо git clone && mvn clean install, еще придётся постгрес качать, разворачивать.

[Borz]

я для Gradle плагин сделал, который можно использовать и тогда разработчику не придётся заморачиваться. Так же под Maven можно сделать.
Это не предложение поменять библиотеку, а озвучивание того, что проблемы как бы и нет в qatools о которых писалось

[Honoured_Nihilist]

Говорят, хорошая примета сперва искать готовые решения :)

https://github.com/honourednihilist/gradle-postgresql-embedded
https://github.com/honourednihilist/gradle-postgresql-embedded-example

[Borz]

наверное стоит дописать в readme почему я не стал его использовать и контрибьютить туда, да? :)
Или сами сравните текущие readme и код там и у меня? ну, чтобы разницу в подходах увидеть...

[Lanwen]

Про «Детище Яндекса» смешно :) На самом деле просто так случилось, что правами на код обладает Яндекс, так как он был написан частично в рабочее время для тестирования в том числе и рабочих проектов. А сейчас вообще меинтейнится человеком, не работающим в Яндексе.

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

[deebun]

Спасибо за пояснение, исправлено.

[smecsia]

postgresql-embedded maintainer here.
Спасибо за статью, кто-то давно должен был написать что-то подобное, поскольку изложенная проблема актуальна долгое время, но при этом ни одной внятной статьи на данную тему я пока не видел.
Когда создавался проект postgresql-embedded, я к сожалению, не нашёл otj-pg-embedded и поэтому на коленке собрал своё решение, которое постепенно приобрело некоторую популярность. Основано оно было на библиотеке, которую использует embed.mongo, а в ней было обнаружилось немало архитектурных проблем, что в итоге сказалось на удобности API… Но история долгая, с тех пор API попричесался, а некоторые изложенные в статье проблемы на текущий момент решены.

Присоединяюсь к предыдущему комментарию — большая просьба подредактировать текст и убрать слова про «Детище Яндекса», поскольку они довольно далеки от реальности.

Хочу также слегка оправдаться за доставку артефакта из внешней сети. Данный вопрос поднимался в issues. На текщий момент это не совсем тривиально, но тем не менее довольно легко сконфигурировать с помощью PostgresDownloadConfigBuilder, который передаётся в RuntimeConfigBuilder. Там можно задать любой источник архивов, в том числе и локальный maven репозиторий.

[igor_suhorukov]

Там можно задать любой источник архивов, в том числе и локальный maven репозиторий.

Теперь можно указывать и артефакт в удаленном maven совместимом репозитарий с помощью MavenDownloader

Тест эмулирует внешний репозитарий.

Про библиотеку по скачиванию артефактов рассказывал в публикации. Она в том числе умеет читать .m2/settings.xml и определять зеркала и т.п.

[Envek]

А не проще ли использовать обычный отдельный PostgreSQL в Docker-контейнере? Нужен постгрес с кастомными расширениями и конфигами? Написал Dockerfile с этим всем и дальше уже проблемы докера — он и установит и соберёт и образ полученный закэширует.

[Borz]

нет, не проще.

тут сейчас как? есть Maven/Gradle и JDK. Запустил и понеслось хоть прям из IDE.

А вы как предлагаете? Отдельно поставить ещё и Docker и потом уже запускаться, да?
Здесь же говорится про запуски со стороны разработчика, а не серверного стенда.

Например у нас применяется гибридная модел — Embedded & Docker

[relgames]

Можно запускать Docker контейнеры прямо из тестов.
Мы используем свой велосипед, но я хочу перейти на TestContainers

[Borz]

которые под капотом используют com.github.docker-java, который под капотом использует установленный в ОС Docker клиент. Вернулись к "поставить ещё и Docker" и к проблеме мультиОС поддержки

[VolCh]

По статье и комментам сложилось впечатление, что всё это актуально только для экосистемы Java. Правильно?

[rraderio]

Какие плюсы есть в сравнении с https://www.testcontainers.org/?

[misterkramer]

А в сторону использования контейнеров не смотрели, тот же Docker? Почему вы используете такой вариант, нежели, к примеру, поднимать контейнер с postgresql при тестировании?
Интересно ваше мнение на этот счёт. Спасибо.

[deebun]

Для прогона тестов на машине разработчика хотелось бы ограничиться Maven'ом, зачем городить дополнительную инфраструктуру?

[AlexWinner]

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

[Nikita]

Такая тестовая инфраструктура в hh тоже есть, но здесь же речь шла о запуске unittest'ов, немного другой уровень проблемы.

[VolCh]

Юнит-тестирование SQL-кода должно не трогать не базу, а остальной код, в данном случае Java похоже. Судя по всему возможностей Hibernate оказалось недостаточно и ребята стали писать SQL-запросы руками. А их надо как-то тестировать.

[viartemev]

У нас есть опыт использования embedded Postgre от Яндекса, из-за этого чуда все работает адски медленно, чем не угодил вариант работы с Docker?

[deebun]

Не хотелось усложнять инфраструктуру для запуска тестов на машинах разработчиков (выше в комментариях уже про это говорили). По поводу скорости — после некоторых оптимизаций, описанных в последней части статьи, в особенности после того, как задействовали пул соединений — тесты стали проходить так же быстро, как и при использовании in-memory базы.

[misterkramer]

Т.е юнит тесты у вас прогоняются непосредственно на машинах разработчиков, не на CI сервере?

[Borz]

вполне нормально, когда часть или все Unit-тесты прогонятся у разработчика "здесь и сейчас", а не ожидая своей очереди на CI сервере.
С другой стороны, та же связка IDEA+TeamCity позволяет отправлять на CI патчи без коммита в VCS с целью протестировать. Хотя это тоже поставит их в очередь.

[misterkramer]

спасибо за ответы!
Еще такой нескромный вопрос — почему в качестве пула выбрали c3p0, а не, к примеру, hikaricp? hikaricp вроде как активно развивается по сравнение с теми же c3p0,bonecp… Или вам было достаточно c3p0 и вы с ним уже работали, поэтому не стали использовать что-то другое?

[Borz]

эм, а вопрос точно мне предназначается?

[misterkramer]

Borz простите.
конечно вопрос был адресован автору статьи — deebun, забыл упомянуть его в предыдущем комментарии…
deebun ответьте, пожалуйста, на этот вопрос, если вам будет не сложно:

Еще такой нескромный вопрос — почему в качестве пула выбрали c3p0, а не, к примеру, hikaricp? hikaricp вроде как активно развивается по сравнение с теми же c3p0,bonecp… Или вам было достаточно c3p0 и вы с ним уже работали, поэтому не стали использовать что-то другое?

[deebun]

Да, все верно. У нас есть опыт использования c3p0 в проектах, поэтому выбрали именно его.

[Borz]

а перейти на HikariCP думаете? он пошустрее будет. Или ваши тесты показали иное? Или "работает и ладно"?

[deebun]

Пробовали HikariCP, кстати, этот пул сейчас используется в продакшене в одном из проектов. C3P0 пока устраивает по скорости, поэтому нет смысла все переводить на Hikari (тем более, был эксперимент еще с одним репозиторием, ощутимого выигрыша в скорости не заметили). Юнит-тесты выполняются одинаково быстро, что с тем, что с другим.

[VolCh]

Там где практикуется TDD часто просто нельзя отправлять коммиты в репу без всех зеленых тестов.

[rraderio]

А где хранятся данные, на диске или в оперативной памяти?
Можно сделать Speedup unit tests by moving MySql data to memory,

[deebun]

Данные хранятся в памяти, об этом раздел «Временные файлы в RAM».