Więc pomyślałem o użyciu trybu zgodności H2 PosgreSQL, myśląc, że wszystkie zapytania postgres będą działać na H2, proszę popraw mnie, jeśli się mylę
Obawiam się, że to nieprawda.
H2 próbuje emulować składnię PostgreSQL i obsługuje kilka funkcji i rozszerzeń. Nigdy nie będzie w pełni dopasowany do zachowania PostgreSQL i nie obsługuje wszystkich funkcji.
Jedyne dostępne opcje to:
- Używaj PostgreSQL w testach; lub
- Przestań używać funkcji nieobsługiwanych przez H2
Proponuję użyć Pg do testowania. Stosunkowo łatwo jest napisać zestaw testowy, który initdb jest instancją postgres i uruchamia go do testowania, a następnie niszczy.
Aktualizacja na podstawie komentarzy:
Nie ma sztywnej granicy między testami „jednostkowym” a „integracyjnym”. W tym przypadku również H2 jest składnikiem zewnętrznym. Purystyczne testy jednostkowe miałyby fikcyjną odpowiedź na zapytania jako część uprzęży testowej. Testowanie na H2 jest tak samo testem „integracyjnym”, jak testowanie na PostgreSQL. Fakt, że jest w trakcie przetwarzania i w pamięci, jest wygodą, ale nie ma znaczenia funkcjonalnego.
Jeśli chcesz testować jednostkowo powinieneś napisać inny cel bazy danych dla swojej aplikacji, który będzie pasował do celów „PostgreSQL”, „SybaseIQ” itp. Nazwij to, powiedz „MockDatabase”. Powinno to po prostu zwrócić oczekiwane wyniki z zapytań. Tak naprawdę nie uruchamia zapytań, istnieje tylko po to, aby przetestować zachowanie reszty kodu.
Osobiście uważam, że to ogromna strata czasu, ale właśnie to zrobiłby purysta testów jednostkowych, aby uniknąć wprowadzania zewnętrznych zależności do wiązki testowej.
Jeśli nalegasz na posiadanie testów jednostkowych (w przeciwieństwie do testów integracyjnych) dla swoich komponentów DB, ale nie możesz/nie chcesz napisać symulowanego interfejsu, musisz zamiast tego znaleźć sposób na użycie istniejącego. H2 byłby rozsądnym kandydatem do tego - ale będziesz musiał napisać nowy backend z nowym zestawem zapytań, który będzie działał dla H2, nie możesz po prostu ponownie użyć swojego backendu PostgreSQL. Jak już ustaliliśmy, H2 nie obsługuje wszystkich funkcji, których potrzebujesz w PostgreSQL, więc będziesz musiał znaleźć różne sposoby, aby zrobić to samo w H2. Jedną z opcji byłoby utworzenie prostej bazy danych H2 z "oczekiwanymi" wynikami i prostymi zapytaniami, które zwracają te wyniki, całkowicie ignorując rzeczywisty schemat aplikacji. Jedyną wadą jest to, że utrzymanie może być poważnym problemem… ale to są testy jednostkowe.
Osobiście testowałbym po prostu z PostgreSQL. O ile nie testuję pojedynczych klas lub modułów, które są samodzielnymi, dobrze zdefiniowanymi jednostkami o wąskim interfejsie, nie obchodzi mnie, czy ktoś nazywa to testem „jednostkowym” czy „integracyjnym”. Przetestuję, powiedzmy, klasy sprawdzania poprawności danych. W przypadku kodu interfejsu bazy danych purystyczny test jednostkowy nie ma większego sensu i zrobię tylko testy integracyjne.
Chociaż posiadanie w toku bazy danych w pamięci jest do tego wygodne, nie jest to wymagane. Możesz napisać swoją wiązkę testową tak, aby kod konfiguracji initdb s nowy PostgreSQL i uruchamia go; następnie kod likwidujący zabija postmastera i usuwa katalog danych. Więcej na ten temat napisałem w tej odpowiedzi.
Zobacz też:
- Uruchamianie PostgreSQL tylko w pamięci
Co do:
Jeśli wszystkie zapytania z oczekiwanymi końcowymi zestawami danych działają poprawnie w Postgress, mogę założyć, że będzie działać dobrze we wszystkich innych bazach danych
Jeśli rozumiem, co mówisz poprawnie, to tak, to prawda — jeśli reszta Twojego kodu działa z zestawem danych z PostgreSQL, powinien zasadniczo działać tak samo z zestawem danych zawierającym te same dane z innej bazy danych. O ile oczywiście używa prostych typów danych, a nie funkcji specyficznych dla bazy danych.
