Така че реших да използвам режим на съвместимост с H2 PosgreSQL, като си помислих, че всички заявки на postgres ще работят на H2, моля, поправете ме, ако греша
Боя се, че това не е вярно.
H2 се опитва да емулира синтаксиса на PostgreSQL и поддържа няколко функции и разширения. Никога няма да съответства напълно на поведението на PostgreSQL и не поддържа всички функции.
Единствените опции, които имате, са:
- Използвайте PostgreSQL при тестване; или
- Спрете да използвате функции, които не се поддържат от H2
Предлагам да използвате Pg за тестване. Сравнително лесно е да се напише тестова система, която initdb е екземпляр на postgres и да се стартира за тестване, след което да се развали след това.
Актуализация въз основа на коментари:
Няма твърда граница между тестовете за "единична" и "интеграционна". В този случай H2 също е външен компонент. Единичните тестове на Purist ще имат фиктивен отговор на запитвания като част от тестовия ремък. Тестването срещу H2 е точно толкова "интеграционен" тест, колкото тестването срещу PostgreSQL. Фактът, че е в процес и в паметта, е удобство, но не е функционално значимо.
Ако искате единичен тест трябва да напишете друга цел на база данни за вашето приложение, която да върви заедно с вашите цели "PostgreSQL", "SybaseIQ" и т.н. Наречете го, кажете, "MockDatabase". Това просто трябва да върне очакваните резултати от заявките. Той всъщност не изпълнява заявките, той съществува само, за да тества поведението на останалата част от кода.
Лично аз мисля, че това е огромна загуба на време, но това е, което пуристът за тестване на единици би направил, за да избегне въвеждането на външни зависимости в тестовата система.
Ако настоявате да имате единични (за разлика от интеграционните) тестове за вашите DB компоненти, но не можете/нямате да напишете макет интерфейс, вместо това трябва да намерите начин да използвате съществуващ такъв. H2 би бил разумен кандидат за това - но ще трябва да напишете нов бекенд с нов набор от заявки, които работят за H2, не можете просто да използвате повторно своя PostgreSQL бекенд. Както вече установихме, H2 не поддържа всички функции, които трябва да използвате с PostgreSQL, така че ще трябва да намерите различни начини да правите същите неща с H2. Една от възможностите е да се създаде проста база данни H2 с "очаквани" резултати и прости заявки, които връщат тези резултати, като напълно се игнорира схемата на реалното приложение. Единственият реален недостатък тук е, че поддържането може да е голяма мъка... но това е тестване на единици.
Лично аз просто бих тествал с PostgreSQL. Освен ако не тествам отделни класове или модули, които са самостоятелни като добре дефинирани единици с тесен интерфейс, не ме интересува дали някой го нарича тест за „единица“ или „интеграция“. Ще тествам единица, да речем, класове за валидиране на данни. За кода на интерфейса на базата данни пуристичното единично тестване няма много смисъл и просто ще направя интеграционни тестове.
Въпреки че наличието на база данни в паметта в процес е удобно за това, не е задължително. Можете да напишете своя тестов ремък така, че кодът за настройка initdb s нов PostgreSQL и го стартира; след това кодът за разрушаване убива администратора на пощата и изтрива datadir. Написах повече за това в този отговор.
Вижте също:
- Изпълнение на PostgreSQL само в паметта
Що се отнася до:
Ако всички заявки с очаквани крайни набори от данни работят добре в Postgress, мога да предполагам, че ще работи добре във всички други dbs
Ако разбирам какво казвате правилно, тогава да, това е така - ако останалата част от кода ви работи с набор от данни от PostgreSQL, като цяло трябва да работи по същия начин с набор от данни, съдържащ същите данни от друга база данни. Стига да използва прости типове данни, а не специфични за базата данни функции, разбира се.
