Richard Šerý v článku Druhá obtížná věc prohlašuje: „pište kód tak, aby ho pocho­pilo i malé děcko, senilní stařík či vy po deseti letech práce v korpo­ra­ci“. V komen­tářích jste mě za podobu unit testu pro validátor rodného čísla, který ono krédo respek­tuje, téměř kameno­vali. Zkusme tedy něco elegant­nějšího: paramet­ri­zo­vaný JUnit test. Dle toho, co jsem viděl, se zatím testy tímto způsobem moc nepíšou. Jako další zlepšovák imple­men­továno v Groovy.

Zadání

Je dán validátor e-mai­lové adresy definován pomocí regulár­ního výrazu. Byl nahlášen bug - délka části před zavináčem nesmí být delší jak 64 znaků. Známý bonmot praví: „Máte-li problém a rozhod­nete se ho řešit regulární výrazem, máte problémy rázem dva“. Pro zajíma­vost (pro samotný test netře­ba), použi­jeme funkcio­na­litu zvanou looka­head assertion.

Test

Než do regulár­ního výrazu jakkoliv sáhnu, napíšu si test. Znamená to vymyslet několik valid­ních a nevalid­ních hodnot. Ty pak lze použít v jednot­livých test metodách (těch je hodně). Nebo naopak napsat jedinou test metodu, kterou nakrmím testo­vacími daty v podobě tabulky, kde jeden sloupec jsou vstupní hodnoty a druhý sloupec očekávané výsledky. Toho dosáh­neme právě runnerem org.junit.runners.Parameterized

Groovy mi pomohlo v lepší práci s kolek­cemi a načtení testo­vaného regulár­ního výrazu z proper­ties souboru.

Nebojte, i když máte jedinou testo­vací metodu, test runner posky­tuje pěkný přehled jednot­livých případů. Tady je příklad, jak to vypadá v IntelliJ IDEA.

Závěr

Paramet­ri­zo­vanými testy dokážete, jak elegantní kód píšete, ale otázkou zůstává, zda se ostatním nebude hůř číst a upravovat.

Mohl by vás zajímat souvi­sející článek: JUnit Theories (Dominik Moštěk)