8 komentáře “Jak na rychlé integrační testy ve Springu

  1. Zpětný odkaz: Nástroje pro podporu vývoje na platformě Java | SKOUMAL

  2. Zrovna teď se mi to bude moc hodit, zavádím testy do projektu, kde je potřeba připravit hodně provázaných dat a měl jsem trochu obavy, jak to udělat aby měl test při každým spuštění čistý data a aby netrval dlouho pro každou metodu.

    Takže Honzo díky 🙂

  3. Jasně – žádné řešení není stoprocentní. Když ladím test, zatím to pro mě problém nebyl, že jsem nevěděl co mám v tu chvíli v databázi – obvykle totiž jeden test nevygeneruje tolik nových dat, které v DB už nejsou před započetím testu.

    Zrychlení a zjednodušení testů rozhodně stojí za tuhle malou nevýhodu.

    Ad 2) v tomto případě to půjde těžko aplikovat – leda na integrační testy subsystému, schovaného za danou WS

    Spíš jde to to, že čím dál víc přicházím na to, že pokud se chce efektivně testovat, tak to obvykle jde – jen na řadu věcí přicházím o dost později, než bych potřeboval nebo chtěl ;).

  4. 1) Problém je v tom, že když potom ladíš test, který běží celý v transakci, nemůžeš se v půlce testu (když je kód zastaven na breakpointu) podívat na data v databázi (jestli jsou v správně).

    2) Naše projekty používají často web servicy (máme stromovou strukturu projektů, které se navzájem využívají pomoci SOAPu) a s těmi mi lokální DB transakce moc nepomůže.

  5. JJ, jasně – tohle je výkonnější varianta. Asi jsem radikální, nechtělo se mi riskovat, že ten programátor špatně uklidí a padne mi to třeba o pět testů dál. Někdy si říkám, že než riskovat takovéhle nepříjemné chyby, je možná lepší stisknout VELKÝ ČERVENÝ KNOFLÍK :).

  6. Ja jsem to myslel tak, ze potomek si udela tu opravu sam. Napriklad meni pouze data jednoho radku, tak je zbytecne aby se musela znovytvaret cela tabulka pripadne cast databaze kvuli referencni integrite. Tahle kompemnzacni metoda by byla jenom volitelna.

  7. No to je přesně to, co dělá AbstractDatabaseSpringTestCase (se základní implementací v AbstractProjectDatabaseTestCase), jehož kód jsem uvedl v článku. Test v takovém případě buď

    a) změní počty řádků v tabulkách – předek to detekuje a refreshne data v DB
    b) zavolá metodu setDatabaseDirty a předek v tearDown zareaguje stejně

    Nicméně řekl bych, že jakmile máš jeden jediný test, který neběží v transakci a modifikuje natvrdo data v databázi, zavírá si tím člověk vrátka ke konkurentnímu běhu více testů najednou – jistota je už ta tam.

  8. Pristup s rollbacknutim transakce rozjete v testu ma jeste jednu vyhodu a to, ze je mozne diky defaultni izolaci transakce bezet vice konkurentnich testu nad jednou databazi a to aniz by se testy ovlivnily. Pokud test potrebuje udelat neco, co zmeni trvale stav databaze a tudiz by doslo k nekonzistenci dat, tak by nebylo spatne poskytnout v tom predkovi kompenzacni metodu, ktera by to vratila do puvodniho stavu. Predek by ji jednak volal a jednak sam implementoval jako prazdnou, potomek by mohl v pripade potreby dodat patricne chovani.