Chtěl bych navázat na článek Paramet­ri­zo­vaný JUnit test a pokrač­ovat tak v předs­ta­vování vlast­ností JUnit, o kterých dost programátoru neví, nebo je alespoň denně nepoužívají.

Jsem zastáncem toho, aby jednot­livé testy byly co nejkratší a samozřejmě na sobě nezávislé. Raději napíšu deset testo­vacích metod s jedním asser­tem, než jednu metodu s deseti asserty (viz kriti­zo­vaný test validátoru rodných čísel). Výhodu spatřuji v tom, že při jediném běhu testu vidíte na jediný pohled všechny vadné případy. A ne že opravíte první assert, spustíte test a padne vám hned druhý assert v pořadí.

Jiné je to v případě integ­rač­ních testů, například Selenium (WebD­ri­ver). Samotná příprava dat je náročná, takže je vhodné asserty sdružovat do větších celků. Ale jak z jediného běhu získat co nejvíce infor­mací, aniž byste museli test znovu a znovu opakovat?

Existuje šikovná imple­men­tace rozhraní TestRule, v podobě ErrorCollector, který sbírá vzniklé chyby, ale repor­tuje je až nakonec.

Ukázka

Násle­duje ukázka Selenium testu (v Groovy), který ověřuje, zda mají povinná pole formuláře kolem sebe rámeček určité barvy. Jiste nechcete test ukončit po zjištěné nesrov­na­losti hned na prvním poli. Zaměřte svou pozor­nost na řádek číslo 35, kde byste psali jako obvykle nějaký assert, ale tentokrát použi­jete ErrorCollectorl#checkThat. Díky anotaci @Delegate můžete vynechat referenci na errorCollector a psát pouze checkThat.

A takhle nějak může vypadat výpis v IntelliJ IDEA

Související