Jan Štěrba

Nechápu jak je možné, že ve stavu absolutního myšlenkového vyčerpání jsem schopen ještě něco tady psát. Asi setrvačnost. V poslední době jsem si osvojil jednu praktiku známou hlavně na open-source projektech a rád bych se o ni podělil.

Test Driven přístup diktující psát první testy a pak kód je sice skvělý, ale zatím se mi této mety nepodařilo dosáhnout na sto procent. Nicméně se tomu snažím maximálně přibližovat. Dnes ale chci psát o něčem jiném. Stará dobrá programnátorská mýlka říká, že z toho že máme testy vyplývá, že naše aplikace funguje dobře. Vedle jak ta jedle, testy testují jenom to co se po nich chce a vždy (ano vždy) se najde škvírka, kterou testy nepokryly a objeví se chyba.

Postup, který jsem na začátku slíbil je jednoduchý. Nejlepší dokumentací chyby je test, který chybu odhalí. Najdu-li v kódu chybu, první co dělám je, že píšu test, při kterém se chyba projevuje. V dalším kroku se chyba odstraní a je po problému.

Celé se to dá rozepsat ještě dále:

1. Je objevena chyba
2. Napíšu test, který díky chybě padá
3. Commituju, kontiuální build padá protože neprošly testy
4. Implementuju opravu pro chybu
5. Commituju, kontinuální build prochází

Bod 3 je velmi zajímavý okamžik procesu. Někomu by se mohlo zdát zlé, že build spadl, ale je to naopak velmi dobré. Od toho máme kontinuální buildy, abychom byli upozorněni když se objeví chyba.

technicka: mylka a vyplyva

V jadru s tebou samozrejme souhlasim, ale budu mit drobnou namitku k prechodu z 1 do bodu 2, ktery vypada na papire trivialne, ale v praxi to muze byt maso.
Pokud mas integracni testy, tak je samozrejme snazsi chybu stimulovat, ale upravy integracnich testu byvaji dost neprijemna prace. A naopak – pokud testujes unity, tak je sice snadne pridat do testovaci tridy dalsi @Test, ale muze byt netrivialni zjistovat, ke ktere jednotce ten test pridat a co presne by mel obsahovat. Navic bod 2 lze snadno aplikovat jen na deterministicke chyby – pokud program skonci s OutOfMemory v jednom z peti behu i pri “stejnych” akcich uzivatele nebo jde o nejakou ezoterickou chybu v threadovani (ktere se obecne blbe testuje), tak je od 1 k 2 cesta dlouha a trnita.

@Satai: Vse zavisi na tom jakou mas testovaci infrastrukturu. Samozrejme ze je nejlepsi kdyz se da chyba popsat automatizovanym testem, ale test muze byt i Test-case pro QA, ktery je ciste slovni navod pro testera jak chybu nasimulovat.

Me k napsani clanku samozrejme privedly moje hratky v Ruby On Rails, kazdopadne to zacinam pouzivat i na ostrych pracovnich projektech kde je mozne a tam taky mnohdy nemame plne automatizovane testy.

Povinná pole jsou vyznačena tučně.