Blog 8 spôsobov, ako mi Test-Driven Development pomôže zlepšiť moju prácu

8 spôsobov, ako mi Test-Driven Development pomôže zlepšiť moju prácu

Test-Driven Development (ďalej len TDD) opísaný v predchádzajúcom článku je na prvý pohľad zvláštny proces, priečiaci sa zdravému rozumu. Veď ako môžeme najprv napísať test a až potom implementáciu? Jednoducho. Presne tak isto, ako môžeme najprv stanoviť, čo chceme naprogramovať a až potom to urobiť.


Pozývame na školenie s Pavlom Bernhauserom: Test-Driven Development, ktoré sa uskutoční 19.5.2020ONLINE o 18:00. ☞ Registrácia na školenie.

Práve táto požiadavka, spolu s postupným striedaním písania testu a implementácie je ten dôvod prečo to funguje a prináša toľko výhod. Poďme sa na ne pozrieť podrobnejšie.

ČO komponent robí vs. AKO to robí

Dopredu napísaný test kladie dôraz na to, čo komponent robí, nie na to, ako to má dosiahnuť. Takýto test je zvyčajne čitateľnejší. Čitateľnosti taktiež pomáha, ak je test krátky a testuje, čo najmenej.

Je pomerne bežné, že test napísaný „až po” presne kopíruje produkčný kód, t.j. je plný ako. Čitateľnosť takých testov je nižšia.

Test slúži ako špecifikácia

Keď potrebujeme do testu zapísať, čo komponent robí, tak musíme rozumieť špecifikácii komponentu.

Samotný test by mal byť jasný a krátky. Jeho meno by malo zodpovedať tomu, čo sa v ňom deje — popisovať, aký scenár testuje. Takto test funguje ako špecifikácia. Vykonateľná, a teda vždy aktuálna.

Naopak, pri tradičnom prístupe sú bežné názvy testov ako testCalculationThrowsException. Z názvu nie je jasné, prečo by mal komponent vyhodiť výnimku. Ak to potrebujeme zistiť, musíme preskúmať test alebo aj produkčný kód.

Testy sú rýchle

TDD negarantuje rýchle testy, ale ak chceme pracovať podľa princípov TDD, tak sa musíme snažiť udržať testy dostatočne rýchle. Inak nás pomalý cyklus začne frustrovať a začneme hľadať skratky. Prestaneme spúšťať testy pred implementáciou komponentu, prípadne spravíme viac cyklov a testy spustíme len raz na konci. Môžeme to tak robiť, ale prídeme o výhody TDD.

Ak neviete dosiahnuť pri nejakom komponente primeranú rýchlosť, tak skúste oddeliť pomalé testy od ostatných a komponent urobiť bez TDD.

Komponent bude dobre nadizajnovaný

Keď píšeme testy až po ukončení vývoja komponentu, tak veľmi často zistíme, že komponent nie je ľahko testovateľný. Buď ho prerobíme, alebo budú testy komplikované a veľké. Prípadne žiadne.

Pri TDD si neviem predstaviť, ako by sa dal napísať produkčný kód, tak aby nebol testovateľný, keďže jeho test existuje skôr.

Testovateľnosť vo svojej podstate znamená, že vieme zobrať komponent a použiť ho nezávisle od kontextu, v ktorom má byť používaný. V našom prípade je to unit test. Ale rovnako ho môžeme zobrať a znovu-použiť v nejakom inom kontexte, o ktorom pôvodný autor ani netušil.

Menej chýb dnes a aj v budúcnosti

Testovateľnosť má vplyv na pokrytie kódu testami. Takto TDD umožňuje dosiahnuť vyššie pokrytie, ktoré chráni pred budúcimi chybami.

Taktiež klesá riziko, že autor testu doň zavedie chybu z produkčného kódu. Toto sa môže ľahko stať ak je produkčný kód napísaný skôr a autor sa ním „inšpiruje” pri písaní testov.

Pomáha vytvoriť ideálne API

Test je prvý klient vyvíjaného komponentu, t.j. vďaka testu musíme rozmýšľať o tom ako sa bude komponent používať ešte skôr ako rozmýšľame o tom, ako dosiahnuť požadovanú funkcionalitu. Keďže testy a komponent vznikajú postupne, tak aj výsledné API máva iný stupeň granularity ako pri tradičnom prístupe.

Okrem toho, TDD pomáha rozbiť riešený problém na podproblémy (riešené inými komponentami) a definovať pre ne API. Viac sa môžete dozvedieť v tomto článku.

Nenastáva syndróm „Veď mi to už funguje”

Keď pomocou TDD vytvoríme test, tak produkčný kód ešte neexistuje. Takže nám nehrozí riziko typické pre písanie testu až po manuálnom otestovaní komponentu. Tým je pocit, že všetko funguje ako má, som skvelý a už len rýchlo dokončiť test(y) a môžem začať robiť na niečom zaujímavejšom.

Takýto pocit nás presvedčí, že odfláknutý test je lepší ako žiadny, najmä, ak tie testy robíme skôr preto, že ich manažment od nás očakáva. Nejaký test napíšem, pridám aj jeden-dva asserty, napríklad assertNotNull na návratovú hodnotu a som hotový.

Test naozaj testuje to, čo má

Požiadavka vytvoriť zlyhávajúci test pred naprogramovaním produkčného kódu je úžasný spôsob ako zabezpečiť, že test neobsahuje chyby.

Keď programujeme testy ku existujúcej funkcionalite, zvyčajne sme radi, keď to celé spustíme a test je zelený. Hurá, ešte tri takéto testy a som hotový. Už som aj tak ráno oznámil na daily standup-e, že úloha je hotová, len dokončím unit testy.

Ale je to naozaj tak? Ak sme nevideli ako tento test dokáže zachytiť nejakú chybu, kde berieme tú istotu, že to naozaj dokáže? Čo ak máme v teste len jednoduchý assertNotNull na návratovú hodnotu, ale metóda vracia nezmysly?

Záver

Skúste sa zamyslieť nad tým, koľko z týchto výhod vám pri písaní testov až po naprogramovaní komponentu chýba. A vôbec, či ich považujete za výhody alebo nie. Ja a mnohí iní programátori áno.

Potrebujete praktickú ukážku ako TDD funguje v praxi? Prihláste sa na toto školenie.

Ďalšie Pavlove články na túto tému:

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžeš odhlásiť.

Pavel Bernhauser
Pavol Bernhauserhttps://testdrivingexpert.com/
Pavel Bernhauser sa venuje programovaniu od detstva. Po skončení Elektrotechnickej Fakulty STU sa tým začal živiť a stále ho programovanie baví. Hoci už odvtedy prešlo viac ako 20 rokov. Písať unit testy ho prinútili v roku 2002. Odvtedy hľadá možnosti, ako to robiť lepšie. Čaro Test-Driven Development objavil asi v roku 2004. Najnovšie začal písať blog Test Driving Expert, kde sa venuje problematike unit testov a testovateľného dizajnu.

Scala Developer/ka

Máš rád svoju slobodu, pracuješ na projektoch, ideálne remote? Staň sa súčasťou startupu, ktorý buduje platformu na podporu maloobchodu a...

Java Software Architect

Mrháš svojim talentom? Urob prvý krok a zistí čo Ti dnešok ponúka. Medziiným aj prácu v medzinárodnej IT spoločnosti,...

Back-End Developer / REMOTE

Pracuj na svetovom SW produkte, ktorý je používaný miliónmi používateľov! Firma rýchlo rastie a vyvíja nové features. Poznáme ich prostredie...

FullStack PHP Developer

Chcel by si dlhodobú spoluprácu, dobré pracovné podmienky, seriózny prístup? Hľadáme FullStack PHP Developera pre spoločnosť, ktorá sa zaoberá...

Python Medior/Senior Developer

Si Python developer, chceš sa naučiť Go, ideálne remote? Spoločnosť, ktorá sa zaoberá pokročilou analýzou dát a automatizáciou marketingu...

Data Scientist / REMOTE

Pre mladý startup vyvíjajúci softvér, ktorý prispieva hráčom k lepšiemu zážitku z hrania, hľadáme Data Scientist. Založili ho dvaja...

IT Aplikačný Architekt

Chceš stabilné zamestnanie, vychutnávať si skvelý kolektív a mať priestor na realizáciu svojich riešení? Pre spoločnosť pôsobiacu v energetike...

Zapojte sa do prvého NCC hackathonu!

Nenechajte si ujsť prvý hackathon Národného kompetenčného centra pre HPC a využite jedinečnú príležitosť podieľať sa na vývoji aplikácie,...

Zviditeľnite sa v médiách ako odborník v oblasti IT

Zaujímajú vás novinky zo sveta IT a chýbajú vám v médiách? Pomôžte budovať povedomie v oblasti informačných technológií a...

Súťaž Scracth Match 2021 zaznamenala nárast, dominovali jej edukatívne hry

Porota celoslovenskej súťaže Scratch Match 2021 už po piaty raz ocenila nádejné programátorky vo veku 8-15 okov. Medzi ocenenými...

Čítaj ďalej:

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžeš odhlásiť.