Så jag tänkte använda H2 PosgreSQL-kompatibilitetsläget genom att tro att alla postgres-frågor kommer att fungera på H2, vänligen rätta mig om jag har fel
Jag är rädd att det inte är sant.
H2 försöker efterlikna PostgreSQL-syntax och stödja några funktioner och tillägg. Det kommer aldrig att vara en fullständig matchning för PostgreSQL:s beteende och stöder inte alla funktioner.
De enda alternativen du har är:
- Använd PostgreSQL i testning; eller
- Sluta använda funktioner som inte stöds av H2
Jag föreslår att du använder Pg för att testa. Det är relativt enkelt att skriva en testsele som initdb är en postgres-instans och starta den för testning och sedan river den.
Uppdatering baserat på kommentarer:
Det finns ingen hård linje mellan "enhets"- och "integrations"-test. I det här fallet är H2 också en extern komponent. Puristenhetstester skulle ha en dummy-svarare på frågor som en del av testselen. Att testa mot H2 är lika mycket ett "integrationstest" som att testa mot PostgreSQL. Det faktum att det är under bearbetning och i minnet är en bekvämlighet, men inte funktionellt signifikant.
Om du vill enhetstesta du bör skriva ett annat databasmål för din app som ska gå tillsammans med dina "PostgreSQL", "SybaseIQ" osv. Kalla det, säg, "MockDatabase". Detta bör bara returnera de förväntade resultaten från frågor. Den kör egentligen inte frågorna, den existerar bara för att testa beteendet för resten av koden.
Personligen tycker jag att det är ett enormt slöseri med tid, men det är vad en enhetstestande purist skulle göra för att undvika att införa externa beroenden i testselen.
Om du insisterar på att ha enhetstester (i motsats till integration) för dina DB-komponenter men inte kan/vill skriva ett mock-gränssnitt, måste du istället hitta ett sätt att använda ett befintligt. H2 skulle vara en rimlig kandidat för detta - men du måste skriva en ny backend med en ny uppsättning frågor som fungerar för H2, du kan inte bara återanvända din PostgreSQL-backend. Som vi redan har konstaterat stöder inte H2 alla funktioner du behöver använda med PostgreSQL så du måste hitta olika sätt att göra samma saker med H2. Ett alternativ skulle vara att skapa en enkel H2-databas med "förväntade" resultat och enkla frågor som returnerar dessa resultat, utan att helt ignorera det verkliga programmets schema. Den enda verkliga nackdelen här är att det kan vara svårt att underhålla ... men det är enhetstestning.
Personligen skulle jag bara testa med PostgreSQL. Såvida jag inte testar enskilda klasser eller moduler som står ensamma som väldefinierade enheter med smala gränssnitt, bryr jag mig inte om någon kallar det för ett "enhets"- eller "integrationstest". Jag ska enhetstesta, säg, datavalideringsklasser. För databasgränssnittskod är puristisk enhetstestning väldigt lite meningsfull och jag ska bara göra integrationstester.
Även om det är bekvämt att ha en minnesdatabas i processen, är det inte nödvändigt. Du kan skriva din testsele så att inställningskoden initdb s en ny PostgreSQL och lanserar den; sedan dödar rivningskoden postmastern och raderar datakatalogen. Jag skrev mer om detta i det här svaret.
Se även:
- Kör endast PostgreSQL i minnet
När det gäller:
Om alla frågor med förväntade slutdatauppsättningar fungerar bra i Postgress kan jag anta att det kommer att fungera bra i alla andra dbs
Om jag förstår vad du säger rätt så ja, så är det fallet - om resten av din kod fungerar med ett dataset från PostgreSQL, bör det i allmänhet fungera på samma sätt med ett dataset som innehåller samma data från en annan databas. Så länge den använder enkla datatyper, inte databasspecifika funktioner, förstås.