Så jeg tænkte på at bruge H2 PosgreSQL-kompatibilitetstilstand ved at tro, at alle postgres-forespørgsler vil fungere på H2, ret mig venligst, hvis jeg tager fejl
Jeg er bange for, at det ikke er sandt.
H2 forsøger at efterligne PostgreSQL-syntaks og understøtte et par funktioner og udvidelser. Det vil aldrig matche PostgreSQL's adfærd fuldt ud, og det understøtter ikke alle funktioner.
De eneste muligheder du har er:
- Brug PostgreSQL i test; eller
- Stop med at bruge funktioner, der ikke understøttes af H2
Jeg foreslår at bruge Pg til test. Det er relativt enkelt at skrive en testsele, som initdb er en postgres-instans og starter den til test og river den ned efter.
Opdatering baseret på kommentarer:
Der er ingen hård linje mellem "enheds" og "integrations" test. I dette tilfælde er H2 også en ekstern komponent. Purist-enhedstests ville have en dummy-svar på forespørgsler som en del af testselen. Test mod H2 er lige så meget en "integrations" test som at teste mod PostgreSQL. Det faktum, at det er i gang og i hukommelsen er en bekvemmelighed, men ikke funktionelt signifikant.
Hvis du vil enhedsteste du bør skrive et andet databasemål for din app, så det kan gå sammen med dine "PostgreSQL", "SybaseIQ" osv.mål. Kald det, sig, "MockDatabase". Dette skulle bare returnere de forventede resultater fra forespørgsler. Den kører ikke rigtig forespørgslerne, den eksisterer kun for at teste adfærden af resten af koden.
Personligt synes jeg, det er et kæmpe spild af tid, men det er, hvad en enhedstest-purist ville gøre for at undgå at indføre eksterne afhængigheder i testselen.
Hvis du insisterer på at få enhedstests (i modsætning til integration) for dine DB-komponenter, men ikke kan/vil skrive en mock-grænseflade, skal du i stedet finde en måde at bruge en eksisterende. H2 ville være en fornuftig kandidat til dette - men du bliver nødt til at skrive en ny backend med et nyt sæt forespørgsler, der virker for H2, du kan ikke bare genbruge din PostgreSQL-backend. Som vi allerede har fastslået, understøtter H2 ikke alle de funktioner, du skal bruge med PostgreSQL, så du bliver nødt til at finde forskellige måder at gøre de samme ting med H2. En mulighed ville være at oprette en simpel H2-database med "forventede" resultater og simple forespørgsler, der returnerer disse resultater, fuldstændig ignorerer den rigtige applikations skema. Den eneste reelle ulempe her er, at det kan være en stor smerte at vedligeholde ... men det er enhedstestning.
Personligt ville jeg bare teste med PostgreSQL. Medmindre jeg tester individuelle klasser eller moduler, der står alene som veldefinerede enheder med snævre grænseflader, er jeg ligeglad med, om nogen kalder det en "enheds"- eller "integrationstest". Jeg vil enhedsteste f.eks. datavalideringsklasser. For databasegrænsefladekode giver puristisk enhedstest meget lidt mening, og jeg vil bare lave integrationstests.
Selvom det er praktisk at have en igangværende hukommelsesdatabase, er det ikke påkrævet. Du kan skrive din testsele, så opsætningskoden initdb s en ny PostgreSQL og lancerer den; så dræber nedrivningskoden postmesteren og sletter datadirigenten. Jeg skrev mere om dette i dette svar.
Se også:
- Kører kun PostgreSQL i hukommelsen
Med hensyn til:
Hvis alle forespørgsler med forventede slutdatasæt fungerer fint i Postgress, kan jeg antage, at det vil fungere fint i alle andre dbs
Hvis jeg forstår, hvad du siger korrekt, så ja, det er tilfældet - hvis resten af din kode arbejder med et datasæt fra PostgreSQL, bør det generelt fungere på samme måde med et datasæt, der indeholder de samme data fra en anden database. Så længe den bruger simple datatyper, ikke databasespecifikke funktioner, selvfølgelig.