Takže mě napadlo použít režim kompatibility H2 PosgreSQL a myslel jsem si, že všechny postgresové dotazy budou fungovat na H2, opravte mě, pokud se mýlím
Obávám se, že to není pravda.
H2 se snaží emulovat syntaxi PostgreSQL a podporuje několik funkcí a rozšíření. Nikdy nebude plně odpovídat chování PostgreSQL a nepodporuje všechny funkce.
Jediné možnosti, které máte, jsou:
- Používejte PostgreSQL při testování; nebo
- Přestaňte používat funkce, které H2 nepodporuje
Pro testování doporučuji použít Pg. Je relativně jednoduché napsat testovací svazek, který je initdb postgresovou instancí a spustí jej pro testování a poté jej strhne.
Aktualizace na základě komentářů:
Mezi testy „jednotky“ a „integrace“ neexistuje žádná tvrdá hranice. V tomto případě je H2 také externí komponenta. Testy puristických jednotek by měly jako součást testovacího svazku figurínu odpovídače na dotazy. Testování proti H2 je stejně "integrační" test jako testování proti PostgreSQL. Skutečnost, že je v procesu a v paměti, je výhoda, ale není funkčně významná.
Pokud chcete test jednotky měli byste pro svou aplikaci napsat další databázový cíl, který půjde vedle vašich cílů „PostgreSQL“, „SybaseIQ“ atd. Říkejte tomu, řekněme, „MockDatabase“. To by mělo vrátit očekávané výsledky z dotazů. Ve skutečnosti nespouští dotazy, existuje pouze pro testování chování zbytku kódu.
Osobně si myslím, že je to obrovská ztráta času, ale právě to by udělal purista na testování jednotek, aby se vyhnul zavádění externích závislostí do testovacího svazku.
Pokud trváte na jednotkových (na rozdíl od integrace) testech pro vaše DB komponenty, ale nemůžete/nechcete napsat simulované rozhraní, musíte místo toho najít způsob, jak použít existující. H2 by pro to byl rozumný kandidát - ale budete muset napsat nový backend s novou sadou dotazů, které fungují pro H2, nemůžete jen znovu použít svůj PostgreSQL backend. Jak jsme již zjistili, H2 nepodporuje všechny funkce, které potřebujete k použití s PostgreSQL, takže budete muset najít různé způsoby, jak dělat stejné věci s H2. Jednou z možností by bylo vytvořit jednoduchou databázi H2 s „očekávanými“ výsledky a jednoduchými dotazy, které tyto výsledky vracejí, zcela ignorujíc schéma skutečné aplikace. Jedinou skutečnou nevýhodou je, že může být velmi obtížné udržovat ... ale to je testování jednotek.
Osobně bych testoval pouze s PostgreSQL. Pokud netestuji jednotlivé třídy nebo moduly, které stojí samostatně jako úzce propojené dobře definované jednotky, je mi jedno, jestli to někdo nazývá „jednotkový“ nebo „integrační“ test. Budu testovat jednotky, řekněme, třídy ověřování dat. Pro kód databázového rozhraní má puristické testování jednotek velmi malý smysl a já udělám pouze integrační testy.
I když je pro to výhodná databáze v průběhu procesu, není to nutné. Svůj testovací svazek můžete napsat tak, že kód nastavení initdb s novým PostgreSQL a spustí jej; pak likvidační kód zabije poštmistra a smaže datadir. Více jsem o tom napsal v této odpovědi.
Viz také:
- Spuštění PostgreSQL pouze v paměti
Pokud jde o:
Pokud všechny dotazy s očekávanými koncovými datovými sadami fungují v Postgress dobře, mohu předpokládat, že budou fungovat dobře ve všech ostatních dbs
Pokud správně rozumím tomu, co říkáte, pak ano, je to tak – pokud zbytek vašeho kódu pracuje s datovou sadou z PostgreSQL, obecně by to mělo fungovat stejně s datovou sadou obsahující stejná data z jiné databáze. Za předpokladu, že používá jednoduché datové typy, nikoli funkce specifické pro databázi, samozřejmě.