Dus ik dacht erover om de H2 PosgreSQL-compatibiliteitsmodus te gebruiken door te denken dat alle postgres-query's op H2 zullen werken, corrigeer me als ik het mis heb
Ik ben bang dat dat niet waar is.
H2 probeert de PostgreSQL-syntaxis te emuleren en ondersteunt een aantal functies en extensies. Het zal nooit een volledige match zijn met het gedrag van PostgreSQL en ondersteunt niet alle functies.
De enige opties die je hebt zijn:
- Gebruik PostgreSQL bij het testen; of
- Stop met het gebruik van functies die niet door H2 worden ondersteund
Ik raad aan om Pg te gebruiken om te testen. Het is relatief eenvoudig om een testharnas te schrijven dat initdb een postgres-instantie is en het start om te testen en het daarna afbreekt.
Update op basis van opmerkingen:
Er is geen harde scheidslijn tussen "eenheids"- en "integratie"-tests. In dit geval is H2 ook een externe component. Puristische eenheidstests zouden een dummy-responder op vragen hebben als onderdeel van het testharnas. Testen tegen H2 is net zo goed een "integratietest" als testen tegen PostgreSQL. Het feit dat het in-process en in-memory is, is een gemak, maar niet functioneel significant.
Als u wilt eenheidstest u zou een ander databasedoel voor uw app moeten schrijven om naast uw "PostgreSQL", "SybaseIQ", enz.-doelen te gaan. Noem het bijvoorbeeld "MockDatabase". Dit zou gewoon de verwachte resultaten van query's moeten retourneren. Het voert niet echt de query's uit, het bestaat alleen om het gedrag van de rest van de code te testen.
Persoonlijk vind ik dat een enorme verspilling van tijd, maar dat is wat een unittestpurist zou doen om te voorkomen dat er externe afhankelijkheden in het testharnas worden geïntroduceerd.
Als je aandringt op het hebben van unit-tests (in tegenstelling tot integratietests) voor je DB-componenten, maar je kunt/wilt geen schijninterface schrijven, dan moet je in plaats daarvan een manier vinden om een bestaande te gebruiken. H2 zou hiervoor een redelijke kandidaat zijn - maar je zult een nieuwe backend moeten schrijven met een nieuwe reeks queries die werken voor H2, je kunt niet zomaar je PostgreSQL-backend hergebruiken. Zoals we al hebben vastgesteld, ondersteunt H2 niet alle functies die u met PostgreSQL moet gebruiken, dus u zult verschillende manieren moeten vinden om dezelfde dingen met H2 te doen. Een optie zou zijn om een eenvoudige H2-database te maken met "verwachte" resultaten en eenvoudige query's die deze resultaten retourneren, waarbij het schema van de echte toepassing volledig wordt genegeerd. Het enige echte nadeel hier is dat het een groot probleem kan zijn om te onderhouden ... maar dat is unit-testing.
Persoonlijk zou ik gewoon testen met PostgreSQL. Tenzij ik afzonderlijke klassen of modules test die op zichzelf staan als goed gedefinieerde eenheden met een nauwe interface, maakt het me niet uit of iemand het een "eenheids" of "integratie" -test noemt. Ik zal unittesten doen, laten we zeggen datavalidatieklassen. Voor database-interfacecode puristische eenheidstests heeft weinig zin en ik doe gewoon integratietests.
Hoewel het handig is om een in-process in-memory database te hebben, is het niet vereist. U kunt uw testharnas zo schrijven dat de setup-code initdb s een nieuwe PostgreSQL en lanceert deze; dan doodt de demontagecode de postmaster en verwijdert de datadir. Ik heb hier meer over geschreven in dit antwoord.
Zie ook:
- PostgreSQL alleen in het geheugen uitvoeren
Wat betreft:
Als alle query's met verwachte einddatasets goed werken in Postgress, kan ik ervan uitgaan dat het goed zal werken in alle andere dbs
Als ik goed begrijp wat je zegt, ja, dat is het geval - als de rest van je code werkt met een dataset van PostgreSQL, zou het over het algemeen hetzelfde moeten werken met een dataset die dezelfde data uit een andere database bevat. Zolang het gebruikmaakt van eenvoudige gegevenstypen en geen databasespecifieke functies natuurlijk.