Miroslav Holec

Software & Cloud Architect

miroslavholec.cz / blog / proc-je-dulezite-psat-unit-testy

Proč je důležité psát unit testy

Miroslav Holec

Publikován 5. dubna 2015 , aktualizace: 29. března 2016 |

Tento článek je starší 18 měsíců a je proto možné, že popisuje postupy nebo technologie, které v uplynulé době mohly doznat výraznějších změn. Názory a myšlenky v tomto článku již nemusí vyjadřovat současné stanovisko autora nebo autorů. Článek byl napsán 5. dubna 2015.

Unit testům jsem na blogu moc prostoru nevěnoval, ale hodlám to změnit. V tomto úvodním (populisticky nazvaném) článku chci trochu rozebrat myšlenky souvisejícím s testováním software a doplnit je o zajímavé související zdroje. Zmíním se především o tom, proč jsou testy důležité a kolik úsilí stojí jejich psaní.

Zbytečnost nebo nezbytnost

Celkově vzato je to jedna z nejzbytečnějších otázek, které v souvislosti s vývojem software vznikly. Unit Testy mají potenciál pomoci učinit aplikaci mnohem odolnější vůči chybám, nutí vývojáře tvořit robustnější design a s tím podporovat i rozšiřitelnost celého řešení. Analogicky si nedokážu představit, že by nějaká letecká společnost uvažovala nad tím, jestli testovat svá letadla při výrobě, jen protože "na to není čas". Jestli důsledkem toho umírají lidé, nebo vznikají jen mimořádné náklady, už je vcelku vedlejší. Když už nějaké to letadlo letí k zemi, je to obvykle tragický problém. Pokud to letecká společnost ustojí, snaží se najít řešení jak problému v budoucnu předejít. Dalším faktem je, že odstranění chyby v momentě kdy ji odhalí build server je podstatně levnější než její (často zbrklá) náprava po odhalení v produkčním prostředí.

Tak jak je to s tím časem

Z odstavce výše trochu vyplývá, že o čas tu vůbec nejde. Nemá ani smysl uvažovat nad tím, o kolik méně se napíše kódu s UT nebo bez UT. Jednak je to neměřitelné a jednak úplně irelevantní. Testování je zkrátka součást procesu vývoje software a vykašlat se na něj je stejné jako bychom uvařili oběd a před podáním ho neochutnali. Netestovat znamená ztrácet čas hledáním a opravováním chyb nebo neustálým předěláváním "hotového" kódu. Jeden můj kolega na to používá výstižnější větu:

Není čas a peníze udělat to pořádně ale je dost času a peněz to třikrát předělat.

Zpočátku se zpomalí vývoj

Pokud není vývojář zvyklý psát testy, je potřeba počítat s tím, že zpočátku bude trvat vše déle. Člověk zkrátka dělá něco nového, co se musí naučit chápat a používat v praxi. Hlavně na začátku se řeší obrovské množství problémů. Jednak těch technických (pořád nepůjde něco mockovat) a jednak těch druhotných (nezvyk začínat psaním testu). Tak to zkrátka je a než se člověk naučí testovat různé vrstvy aplikace a podchytí všechny praktiky, trvá to.

Začít s testováním je ideální na novém projektu. Osobně jsem si pro testování založil vlastní projekt typu Web API, který má za úkol v podstatě jen tahat články z databáze a vracet je jako JSON. Další funkce aplikace si vymýšlím podle libosti, když mě napadne nějaká nová situace, abych ji zkusil vyřešit. Pokud se naskytne možnost pracovat na vlastním novém projektu, je to o to lepší. Začít psát testy na existujícím projektu je možné taky, ale ta věta o "zpomalení vývoje" platí několikanásobně, jelikož budete nuceni dost věcí zcela redesignovat. Je nutné smířit se s tím, že dopsat novou funkci pak nemusí trvat 2 hodiny ale i 2 dny. A to může být pro leckoho problém. Pro myšlenky "ono to musí být za hodinu hotové" nebo "potřebuji okamžitě publikovat aplikaci" a "nechce se mi to kvůli testům celý den přepisovat" není v TDD prostor.

Unit testy jsou svaté.

Napsáním testů není bohužel zaručeno, že pokrytá část aplikačního kódu je bezchybná. Na jedné straně totiž platí, že napsané testy nemusí pokrýt všechny scénáře a na druhé straně můžete napsat test špatně (čímž vlastně vyžadujete i chybnou implementaci). Pokud tedy test selže, je dobré sledovat nejen aplikační kód ale i návrh celého testu. Všechny tyto problémy se nejlépe eliminují testem "více očí" / párovým / paralelním programováním.

Jednoho dne

U většiny softwarových projektů se uvádí, že 80 % času stráví vývojář údržbou stávajících systémů (zdroj). Součástí údržby je neustálé procházení (čtení) kódu, opravy, změny, rozšiřování, zužování a zlepšování stávajícího řešení. Když se dělá nový projekt, vývojáři zkrátka jenom "plodí" kód. Když už někam musí sáhnout kvůli úpravám, "mají to v hlavě" a ví, kde "to" najít. Zeptají se mezi sebou. Nebojí se do kódu sáhnout, a když ano, zase se zeptají. Tým ale často nemyslí na to, co se stane, až bude produkt "jakože hotový". Chcete vážně vědět, co se stane?

Větší část týmu si vezme svých pět švestek a jde dělat zase na něčem novém.

A to je problém. Protože noví vývojáři už tráví čas zmíněnou údržbou. Nemají "to" v hlavě, neví kde "to" najít a nemají se koho zeptat. Prochází kódem sem a tam a bojí se kamkoliv sáhnout, protože bez testů se většina chyb projeví až v produkci. Až když zákazník zavolá, že "ono to nefunguje".

Jak tedy začít

Pokud máte pocit, že to trochu dává smysl a chcete začít s psaním testů, čeká vás hodně práce. Kdybych měl odkázat na jediný zdroj, kterým začít, je to Art Of Unit Testing (web, kniha i videotutoriály). Kniha pracuje s frameworky NUnit a Rhino Mocks. Dalším potenciálním zdrojem může být Pluralsight.

Nakonec snad ještě poznámka pod čarou. Psát testy bez schopnosti praktické aplikace návrhových principů a vzorů je celkem problém.

Pokud Vám nejsou pojmy DI, GoF, SOLID, LoD nebo AOP příliš blízké, asi Vás bude ještě před válčením s unit testy čekat několik menších bitev.

Potřebujete pomoci?

Líbil se Vám článek? Máte dotaz nebo chcete v této oblasti s něčím pomoci? Neváhejte se na mě obrátit.

mirek@miroslavholec.cz

  • Řešení vývojářských problémů
  • Konzultace
  • Firemní školení a workshopy