U svakom backend projektu dođe trenutak kada H2 počne da deluje kao lažna sigurnost. Testovi su zeleni, migracije prolaze, ali produkcija kaže: „Jok“. Tada Testcontainers deluju kao jedini logičan korak. Prava baza, pravi broker, realno ponašanje sistema. Ipak, budimo realni: u tom trenutku ne ubacujete samo novi dependency, već u build proces uvodite infrastrukturu koja iz korena menja pravila igre.
Prvo pitanje koje sebi morate postaviti je: koji problem tačno rešavam? Ako imate bug koji se javlja samo na MySQL-u zbog vendor-specifične funkcije, testiranje sa pravom bazom ima smisla. Ako su migracije pucale jer in-memory baza nije verno simulirala constraint ponašanje, ima smisla. Ali ako je motiv isključivo „da budemo bliže produkciji“, bez konkretnog rizika koji pokrivate, verovatno uvodite složenost bez realne dobiti. Test strategija mora da prati realne slabosti sistema, a ne trendove sa konferencija.
Druga stvar je činjenica da Docker od tog trenutka postaje deo vašeg test sloja. To više nije samo Java ili .NET. To je Docker engine, verzija API-ja, OS layer i memory limit koji je neko podesio u Docker Desktopu. Build stabilnost više nije isključivo u rukama aplikacionog koda. Odjednom morate da razmišljate o verzijama, pinovanju i specifičnostima CI okruženja. To je ozbiljnija odgovornost nego što deluje na prvi pogled.
Onda dolazi potrošnja resursa. Spring Boot test sa punim kontekstom je već težak, a kada na to dodate MySQL kontejner, migracije, Redis ili Kafku, test suite počinje da jede gigabajte RAM-a. Ako paralelizujete testove, svaki thread može pokušati da podigne svoj kontejner. Ako koristite reusable kontejnere, morate savršeno da resetujete state. U suprotnom dobijate testove koji zavise od redosleda izvršavanja, što je posebna vrsta inženjerske noćne more.
Testcontainers nisu samo „malo sporiji testovi“. To je runtime unutar runtime-a. Ako CI runner nema dovoljno resursa, testovi postaju flakey. Čim testovi postanu nepouzdani, tim počinje da ih ignoriše, a to je trenutak kada test gubi svaku svrhu.
Rollback koji je u H2 svetu delovao kao magija odjednom više nije dovoljan. Dok ste u okviru @Transactional anotacije, baza se uvek vraća u početno stanje. Međutim, čim uvedete asinhrone tokove, event publish, outbox pattern ili schedulere, rollback više ne garantuje čist state. Morate odlučiti: da li se oslanjate na lifecycle samog kontejnera ili na ručno čišćenje podataka? Svaka opcija ima svoju cenu u performansama.
U mikroservisnim sistemima situacija se dodatno komplikuje. Ako u integracionom testu podignete bazu, broker, cache i još jedan zavisni servis, vaš build postaje mini deployment. Testcontainers su odlični za komponentni test, ali nisu zamena za pravi E2E na stagingu. Ako pokušate da ih koristite kao full system test, shvatićete da ste praktično implementirali orkestraciju unutar build procesa.
Postavlja se i pitanje feedback loop-a. Ako integracioni test traje nekoliko minuta i izvršava se na svakom commit-u, usporavate razvoj i frustrirate tim. Slojevitost je neophodna: brz unit feedback, selektivni integration test, a pravi E2E tamo gde mu je mesto. Sve u jednom sloju je recept za propast.
Možda i najbitnije: ko je vlasnik te odluke? Testcontainers nisu „set and forget“ alat. Verzije se menjaju, Docker se menja, CI se menja. Ako niko ne održava tu infrastrukturu, za par meseci ćete dobiti suite koji svi zaobilaze. Nepouzdan test je gori od testa koji ne postoji.
Na kraju se sve svodi na dilemu: da li želite test koji simulira produkciju ili test koji daje brz feedback? Možete imati oba, ali ne u istom sloju i ne besplatno. Testcontainers su moćan alat koji u pravom sistemu značajno podiže sigurnost, ali u pogrešnom postaje teret koji troši resurse bez realne koristi.
Ozbiljnost projekta se ne meri upotrebom najnovijih alata, već razumevanjem kompromisa (trade-off) koji prihvatate. U jednom trenutku vaš test suite prestaje da bude samo provera koda i postaje deo arhitekture. Tu leži ključ uspeha ili razlog za budući tehnički dug.
0 komentara