В нашем проекте целевая БД PostreSQL. Бизнес логика пишется на Java, но в DAO пишется много SQL. Возникает задача юнит тестирования. Причём как уровня сервисов (нужны моки БД), так и уровня DAO.
Сейчас сделано так: юнит тесты разворачивают в памяти БД и запускают на ней честные (без моков) сервисы и DAO. В большинстве случаев всё проходит хорошо, но иногда возникают проблемы. Например мне так и не удалось найти 100% синтаксически совместимую с Postgres БД.
HSQL отвергли сразу, так как не смотря на заявления разработчиков она не понимает всех alias для типов данных. Это критично так как DDL генерируется специальными инструментами.
H2 тоже не устраивает тем, что поведение bigserial типов отличается от оригинального Postgres (на лету не создаются sequence). Кроме того, в H2 очень скромные возможности хранимых процедур по сравнению с Postgres. Например не получилось сделать SELECT из хранимки, которая возвращает ResultSet. H2 просто не понимает что он неё хотят.
Вопрос такой. Сталкивался ли кто-нибудь с подобными проблемами и как это можно решить?
В чём проблема использовать, собственно, постгрес для тестирования? Пусть разработчик установит постгрес себе, создаст базу, пользователя и вперёд. Можно эти тесты сделать опциональными, чтобы не запускать каждый раз. Постгрес это не какой-нибудь, прости господи, оракл, который без бутылки не поставишь, там вроде всё просто. Можно даже Docker использовать, чтобы совсем просто было, сейчас это модно.
On 11.12.2014 13:05, telek1024 wrote:
> В нашем проекте целевая БД PostreSQL. Бизнес логика пишется на Java, но > в DAO пишется много SQL. Возникает задача юнит тестирования. Причём как > уровня сервисов (нужны моки БД), так и уровня DAO. > Сейчас сделано так: юнит тесты разворачивают в памяти БД и запускают на > ней честные (без моков) сервисы и DAO. В большинстве случаев всё > проходит хорошо, но иногда возникают проблемы. Например мне так и не > удалось найти 100% синтаксически совместимую с Postgres БД.
Здравствуйте, telek1024, Вы писали:
T>Вопрос такой. Сталкивался ли кто-нибудь с подобными проблемами и как это можно решить?
Ды легко. Берёте https://www.docker.com/, делаете образ какой-нибудь убунты с постгресом, перед тестами поднимаете, после тестов выключаете. Любые проблемы конфигурационного характера исключены если все девелоперы используют один и тот же образ. Для каждого прогона контейнер будет чистым если намеренно не сохранять. Поднимается оно всё за десятки минут.
Здравствуйте, telek1024, Вы писали:
T>Добрый день.
T>В нашем проекте целевая БД PostreSQL. Бизнес логика пишется на Java, но в DAO пишется много SQL. Возникает задача юнит тестирования. Причём как уровня сервисов (нужны моки БД), так и уровня DAO.
T>Сейчас сделано так: юнит тесты разворачивают в памяти БД и запускают на ней честные (без моков) сервисы и DAO. В большинстве случаев всё проходит хорошо, но иногда возникают проблемы. Например мне так и не удалось найти 100% синтаксически совместимую с Postgres БД.
T>HSQL отвергли сразу, так как не смотря на заявления разработчиков она не понимает всех alias для типов данных. Это критично так как DDL генерируется специальными инструментами.
T>H2 тоже не устраивает тем, что поведение bigserial типов отличается от оригинального Postgres (на лету не создаются sequence). Кроме того, в H2 очень скромные возможности хранимых процедур по сравнению с Postgres. Например не получилось сделать SELECT из хранимки, которая возвращает ResultSet. H2 просто не понимает что он неё хотят.
T>Вопрос такой. Сталкивался ли кто-нибудь с подобными проблемами и как это можно решить?
Можно попробовать запускать настоящий постгрес в docker. Для докера написано несколько клиентов на джава, так что несложно будет поднимать контейнер при старте теста.
Здравствуйте, hrensgory, Вы писали:
h> А почему не запускаете тесты на самом PostgreSQL?
+1
Стоит уточнить, что это должны быть тесты только для слоя DAO, сервисы тестить обычными юнит-тестами мокая DAO.
h> Типа такого: h> create database h> ... h> drop database
Можно взять ещё например liquibase для удобства.
