Então eu pensei em usar o modo de compatibilidade H2 PosgreSQL pensando que todas as consultas postgres funcionarão em H2 por favor me corrija se eu estiver errado
Receio que isso não seja verdade.
O H2 tenta emular a sintaxe do PostgreSQL e oferece suporte a alguns recursos e extensões. Nunca será uma correspondência completa para o comportamento do PostgreSQL e não suporta todos os recursos.
As únicas opções que você tem são:
- Usar PostgreSQL em testes; ou
- Parar de usar recursos não compatíveis com H2
Sugiro usar Pg para testar. É relativamente simples escrever um equipamento de teste que initdb é uma instância do postgres e lançá-lo para teste e depois derrubá-lo.
Atualização com base nos comentários:
Não há uma linha dura entre os testes de "unidade" e de "integração". Neste caso, H2 também é um componente externo. Os testes de unidade puristas teriam um respondedor fictício para consultas como parte do equipamento de teste. Testar contra H2 é tanto um teste de "integração" quanto testar contra PostgreSQL. O fato de estar em processo e na memória é uma conveniência, mas não funcionalmente significativo.
Se você quiser teste unitário você deve escrever outro destino de banco de dados para seu aplicativo para acompanhar seus destinos "PostgreSQL", "SybaseIQ", etc. Chame-o, digamos, "MockDatabase". Isso deve retornar apenas os resultados esperados das consultas. Ele realmente não executa as consultas, existe apenas para testar o comportamento do restante do código.
Pessoalmente, acho que é uma grande perda de tempo, mas é o que um purista de teste de unidade faria para evitar a introdução de dependências externas no equipamento de teste.
Se você insiste em ter testes de unidade (em oposição à integração) para seus componentes de banco de dados, mas não pode/não quer escrever uma interface simulada, você deve encontrar uma maneira de usar uma existente. H2 seria um candidato razoável para isso - mas você terá que escrever um novo backend com um novo conjunto de consultas que funcionem para H2, você não pode simplesmente reutilizar seu backend PostgreSQL. Como já estabelecemos, o H2 não suporta todos os recursos que você precisa para usar com o PostgreSQL, então você terá que encontrar maneiras diferentes de fazer as mesmas coisas com o H2. Uma opção seria criar um banco de dados H2 simples com resultados "esperados" e consultas simples que retornassem esses resultados, ignorando completamente o esquema da aplicação real. A única desvantagem real aqui é que pode ser uma grande dor para manter ... mas isso é teste de unidade.
Pessoalmente, eu apenas testaria com o PostgreSQL. A menos que eu esteja testando classes ou módulos individuais que são independentes como unidades bem definidas de interface estreita, não me importo se alguém o chama de teste de "unidade" ou "integração". Vou testar a unidade, digamos, classes de validação de dados. Para o teste de unidade purista de código de interface de banco de dados faz muito pouco sentido e farei apenas testes de integração.
Embora ter um banco de dados em memória em processo seja conveniente para isso, não é necessário. Você pode escrever seu equipamento de teste para que o código de configuração
initdb s um novo PostgreSQL e o lança; então o código de desmontagem mata o postmaster e exclui o datadir. Eu escrevi mais sobre isso nesta resposta. Veja também:
- Executando o PostgreSQL somente na memória
Quanto a:
Se todas as consultas com conjuntos de dados finais esperados funcionarem bem no Postgress, posso assumir que funcionará bem em todos os outros bancos de dados
Se entendi o que você está dizendo corretamente, sim, esse é o caso - se o resto do seu código funciona com um conjunto de dados do PostgreSQL, geralmente deve funcionar da mesma forma com um conjunto de dados contendo os mesmos dados de outro banco de dados. Desde que esteja usando tipos de dados simples e não recursos específicos do banco de dados, é claro.
