Richard Šerý v článku Druhá obtížná věc prohlašuje: „pište kód tak, aby ho pochopilo i malé děcko, senilní stařík či vy po deseti letech práce v korporaci“. V komentářích jste mě za podobu unit testu pro validátor rodného čísla, který ono krédo respektuje, téměř kamenovali. Zkusme tedy něco elegantnějšího: parametrizovaný JUnit test. Dle toho, co jsem viděl, se zatím testy tímto způsobem moc nepíšou. Jako další zlepšovák implementováno v Groovy.

Zadání

Je dán validátor e-mailové adresy definován pomocí regulární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 rozhodnete se ho řešit regulární výrazem, máte problémy rázem dva“. Pro zajímavost (pro samotný test netřeba), použijeme funkcionalitu zvanou lookahead assertion.

Test

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

Groovy mi pomohlo v lepší práci s kolekcemi a načtení testovaného regulárního výrazu z properties souboru.

Nebojte, i když máte jedinou testovací metodu, test runner poskytuje pěkný přehled jednotlivých případů. Tady je příklad, jak to vypadá v IntelliJ IDEA.

Závěr

Parametrizovaný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 související článek: JUnit Theories (Dominik Moštěk)