Режим H2 postgresql, похоже, не работает для меня

Question

Режим H2 postgresql, похоже, не работает для меня

привет, мое приложение обращается к базе данных Postgres,и у меня есть много предопределенных запросов(ранг,раздел, сложное соединение и т. д.), Я стреляю против Postgres. Теперь я хочу пойти на модульное тестирование поведения этих запросов с небольшими тестовыми данными. Поэтому я начал с H2 / Junit. Я узнал, что большинство запросов Postgres, таких как ранг, раздел, сложный случай при обновлении и т. д. Поэтому я подумал об использовании режима совместимости H2 PosgreSQL, подумав, что все запросы postgres будут работать на H2, пожалуйста, исправьте меня, если я неправильный.

я следовал документации H2, говоря, чтобы использовать режим PostgreSQL, используйте URL базы данных jdbc: h2:~/test;MODE=PostgreSQL или режим набора инструкций SQL PostgreSQL.

Я включил режим с помощью SET MODE PostgreSQL и я попытался запустить один из запросов, который включает rank () и работает в postgres, но он не работал H2. Это дает мне следующее исключение

Function "RANK' not found; in SQL statement

пожалуйста, руководство я новичок в H2 и тестирование базы данных. Спасибо заранее. Я использую драйвер H2 jdbc для запуска запросы postgres, думая, что режим совместимости H2 Posgress позволит мне запускать запросы postgres.

14

h2 java jdbc postgresql

автор: u449355

1 ответов

автор: Craig Ringer · Accepted Answer · 2017-05-23 10:31:35

поэтому я подумал об использовании режима совместимости H2 PosgreSQL, думая, что все запросы postgres будут работать на H2, пожалуйста, исправьте меня, если я ошибаюсь

боюсь, что это не так.

H2 пытается эмулировать синтаксис PostgreSQL и поддерживает несколько функций и расширений. Он никогда не будет полностью соответствовать поведению PostgreSQL и не поддерживает все функции.

единственные варианты, которые у вас есть:

использовать PostgreSQL в тестирование; или
прекратить использование функций, не поддерживаемых H2

Я предлагаю использовать Pg для тестирования. Относительно просто написать тестовый жгут, который initdb является экземпляром postgres и запускает его для тестирования, а затем разрывает его.

обновление на основе комментариев:

нет жесткой линии между тестами" unit "и" integration". В этом случае H2 также является внешним компонентом. Модульные тесты Purist будут иметь фиктивный ответчик на запросы как часть тестовой программы. Тестирование на H2 - это такой же" интеграционный " тест, как и тестирование на PostgreSQL. Тот факт, что он находится в процессе и в памяти, является удобством, но не функционально значимым.

Если вы хотите единица теста вы должны написать другую цель базы данных для вашего приложения, чтобы идти рядом с вашими целями" PostgreSQL"," SybaseIQ " и т. д. Назовите это, скажем, "MockDatabase". Это должно просто возвращать ожидаемые результаты из запросов. На самом деле он не управляет запросы, он существует только для проверки поведения остальной части кода.

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

Если вы настаиваете на модульных (в отличие от интеграции) тестах для ваших компонентов БД, но не можете/не хотите писать макет интерфейса, вы должны вместо этого найти способ использовать существующий. H2 был бы разумным кандидатом для этого, но вам придется написать новый бэкэнд с новым набором запросов, которые работают для H2, вы не можете просто повторно использовать свой бэкэнд PostgreSQL. Как мы уже установили, H2 не поддерживает все функции, которые вам нужно использовать с PostgreSQL, поэтому вам придется найти разные способы сделать то же самое с H2. Одним из вариантов было бы создать простую базу данных H2 с "ожидаемыми" результатами и простыми запросами, которые возвращают эти результаты, полностью игнорируя схему реального приложения. Единственный реальный недостаток здесь что это может быть большой болью для поддержания ... но это модульное тестирование.

лично я бы просто тестировал с PostgreSQL. Если я не тестирую отдельные классы или модули, которые стоят отдельно как узко сопряженные четко определенные единицы, мне все равно, кто называет это "блоком" или "интеграционным" тестом. Я проведу модульный тест, скажем, классы проверки данных. Для интерфейса базы данных модульное тестирование кода purist имеет очень мало смысла, и я просто сделаю интеграционные тесты.

во время для этого удобна база данных in-process in-memory, она не требуется. Вы можете написать свой тестовый жгут, чтобы код установки initdbs новый PostgreSQL и запускает его; затем код демонтажа убивает почтмейстера и удаляет datadir. Я написал больше об этом в ответ.