Жаль, что ваш вопрос был отвергнут без обсуждения того, почему.Другие считают это неясным или недостаточно конкретизированным?Трудно сказать.
Я хотел бы предложить, что написание некорректных классов моделей, чтобы H2 мог заменить Postgress, - плохая идея.Скорее всего, это приведет к несоответствию между набором тестов и рабочим кодом, которое будет сложно поддерживать.Более того, тесты, основанные на неправильных моделях, могут оказаться бесполезными.Возможно, они используют базу данных, а не модели или что-то важное, касающееся приложения.В завершение предположим, что вы или кто-то еще хотели подключить тесты для тестирования производительности в какой-то момент в будущем;тесты, использующие неправильные модели против неправильных dbms, были бы бесполезны.
Я предпочитаю придерживаться одних и тех же dbms по всему конвейеру - dev, test, staging, prod и т. д. Я знаю, что это не редкостьиспользовать разные базы данных в определенных местах ради скорости или из-за проблем с лицензированием, но если я не буду этого делать, я не буду.В вашем случае я могу придумать несколько вариантов.
Embeded Postgress.Я видел несколько проектов для встраивания Prostgres.Посмотрите вокруг, попробуйте несколько, придерживайтесь того, что кажется вам подходящим.
Попробуйте RAM-диск или tmpfs .Linux может создавать файловые системы на основе памяти;создайте его, смонтируйте и позвольте Postgres использовать его.Проведите некоторое тестирование, чтобы увидеть, действительно ли оно дает значительные преимущества в производительности.Другие операционные системы могут иметь аналогичные возможности.
Использовать стандартный Postgress.Запустите тесты на стандартной установке Postgress;Другими словами, ничего сложного, преждевременная оптимизация, просто выберите самый простой и прямой путь.Это то, что я бы сделал.
Замените Postgres на H2 ... но не делайте.Я использую и H2, и Postgress, и мне они оба нравятся, но вы уже используете Postgres в prod, поэтому нет веских причин для изменения.
Удачи.