Quindi ho pensato di utilizzare la modalità di compatibilità PosgreSQL H2 pensando che tutte le query postgres funzioneranno su H2, per favore correggimi se sbaglio
Temo che non sia vero.
H2 tenta di emulare la sintassi PostgreSQL e di supportare alcune funzionalità ed estensioni. Non sarà mai una corrispondenza completa per il comportamento di PostgreSQL e non supporta tutte le funzionalità.
Le uniche opzioni che hai sono:
- Usa PostgreSQL nei test; o
- Smetti di usare le funzioni non supportate da H2
Suggerisco di utilizzare Pg per il test. È relativamente semplice scrivere un cablaggio di test che initdb sia un'istanza postgres e lo avvii per il test, quindi lo demolisca dopo.
Aggiornamento basato sui commenti:
Non esiste una linea dura tra i test "unità" e "integrazione". Anche in questo caso H2 è un componente esterno. I test unitari puristi avrebbero un risponditore fittizio alle query come parte del cablaggio di test. Il test contro H2 è un test di "integrazione" tanto quanto il test contro PostgreSQL. Il fatto che sia in-process e in memoria è una comodità, ma non funzionalmente significativa.
Se vuoi test unitario dovresti scrivere un altro target di database per la tua app da affiancare ai tuoi target "PostgreSQL", "SybaseIQ", ecc. Chiamalo, diciamo, "MockDatabase". Questo dovrebbe semplicemente restituire i risultati attesi dalle query. In realtà non esegue le query, esiste solo per testare il comportamento del resto del codice.
Personalmente, penso che sia una gigantesca perdita di tempo, ma è ciò che farebbe un purista di unit test per evitare di introdurre dipendenze esterne nel cablaggio di test.
Se insisti per avere test unitari (anziché di integrazione) per i tuoi componenti DB ma non puoi/non vuoi scrivere un'interfaccia fittizia, devi invece trovare un modo per usarne una esistente. H2 sarebbe un candidato ragionevole per questo, ma dovrai scrivere un nuovo back-end con un nuovo set di query che funzionino per H2, non puoi semplicemente riutilizzare il tuo back-end PostgreSQL. Come abbiamo già stabilito, H2 non supporta tutte le funzionalità che devi utilizzare con PostgreSQL, quindi dovrai trovare modi diversi per fare le stesse cose con H2. Un'opzione sarebbe quella di creare un semplice database H2 con risultati "previsti" e query semplici che restituiscano quei risultati, ignorando completamente lo schema dell'applicazione reale. L'unico vero aspetto negativo qui è che può essere un grosso problema da mantenere ... ma questo è il test unitario.
Personalmente, proverei semplicemente con PostgreSQL. A meno che non stia testando singole classi o moduli che si distinguono da soli come unità ben definite con interfaccia stretta, non mi interessa se qualcuno lo chiama test di "unità" o "integrazione". Testerò unità, diciamo, classi di convalida dei dati. Per il codice dell'interfaccia del database, il test unitario purista non ha molto senso e farò solo test di integrazione.
Sebbene sia conveniente disporre di un database in-memory in-process, non è necessario. Puoi scrivere il tuo cablaggio di prova in modo che il codice di configurazione initdb s un nuovo PostgreSQL e lo lancia; quindi il codice di smontaggio uccide il postmaster ed elimina la datadir. Ho scritto di più su questo in questa risposta.
Vedi anche:
- Esegui PostgreSQL solo in memoria
Quanto a:
Se tutte le query con i set di dati finali previsti funzionano correttamente in Postgress, posso presumere che funzionerà correttamente in tutti gli altri db
Se ho capito bene quello che stai dicendo, allora sì, è così, se il resto del tuo codice funziona con un set di dati di PostgreSQL, generalmente dovrebbe funzionare allo stesso modo con un set di dati contenente gli stessi dati di un altro database. A condizione che utilizzi tipi di dati semplici non funzionalità specifiche del database, ovviamente.
