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ť.

DevOps Enginner / Online Bezpečnosť

Pre IT spoločnosť, ktorá sa venuje online bezpečnosti hľadáme do tímu DevOps Medior Engineer. Spoločnosť má 20-členný tím s...

Senior Java Consultant

Hľadáš, kam by si sa posunul? Možno ťa táto práca zaujme. Ide o Senior JAVA konzultanta v nadnárodnej IT...

Ruby on Rails Junior-Medior Developer / REMOTE

Je tvoj život príliš v “koľajniciach”? Urob si odbočku a skús sa pridať do tímu Ruby on Rails developerov.Ide...

JS Sencha Senior Developer / Homeoffice

Máš rád svoju slobodu, pracuješ na projektoch, ideálne remote? Pre medzinárodnú softwarovú spoločnosť hľadáme JS Sencha Developera.Po dvoch týždňoch...

Junior Angular Developer / REMOTE

Pre nášho partnera hľadáme ITčkára na pozíciu Angular Developer. Spoločnosť sa venuje vývoju platformy pre firmy na znižovanie nákladov...

Frontend Medior Developer

Medzinárodná IT spoločnosť, ktorá vyvíja finančný softvér.Práca je v Bratislave na TPP. Odmena sa pohybuje od 2000+ EUR.Tvoje úlohy...

.NET Core Medior Developer / REMOTE

Svoju budúcnosť máš vo svojich rukách, skús to teraz ako .NET Core developer. Ide o startup projekt, ktorý vyvíja...

GIRL ́S DAY 2020: Už po siedmy raz môžu stredoškoláčky nahliadnuť do IT firiem po celom Slovensku.

Občianske združenie Aj Ty v IT už siedmy rok prepája IT firmy a organizácie so stredoškoláčkami po...

DIGITALEUROPE: Na digitalizáciu pôjde z plánu obnovy až pätina prostriedkov. Ako zareaguje Slovensko?

Výzva v podobe zníženej globálnej konkurencieschopnosti, ako aj kríza spojená s pandémiou postavili Európu...

OpenSlava 2020 tentokrát online!

OpenSlava 2020 je 8. ročník úspešnej konferencie pre IT komunitu na Slovensku...

Čí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ť.