Blog 8 dôvodov, prečo je TDD príjemný spôsob vývoja softvéru

8 dôvodov, prečo je TDD príjemný spôsob vývoja softvéru

V predchádzajúcom článku sme sa venovali dôvodom, prečo je Test-Driven Development (ďalej len TDD) lepší ako programovanie testov až po produkčnom kóde. Ten článok bol zameraný na výhody pre produkt a firmu.


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


Je čas pozrieť sa na to, ako TDD môže pomôcť mne ako programátorovi. Takže dnes sa pozrieme na psychologické výhody TDD:

Po každom cykle vieme, že sme sa posunuli ďalej

Vývoj s použitím TDD je iteratívny. Po ukončení každého krátkeho cyklu vieme, že sme sa posunuli dopredu. A to vo viacerých aspektoch:

  • Sme bližšie k hotovému riešeniu.
  • Dizajn API je viac rozvinutý.
  • Suita testov je kompletnejšia.
  • Naše porozumenie riešeného problému rastie.
  • Naša dôvera v komponent rastie s tým ako rastie jeho funkcionalita.

Rýchla spätná väzba, či robíme správnu vec

Každý cyklus trvá len pár minút a tak dlho trvá kým dostaneme spätnú väzbu o poslednom kroku.

Dozvieme sa napríklad toto:

  • Ak nám vrámci posledného kroku začalo zlyhávať viac testov, môžeme sa zamyslieť nad dôvodmi. Môžeme si uvedomiť, že riešeniu celkom dobre nerozumieme, alebo sme sa v poslednom kroku snažili o príliš veľký prírastok kódu.
  • Či sa navrhované API uberá správnym smerom. Ak sme museli prerobiť API dokončené v predchádzajúcich krokoch, je to signál, že treba spomaliť a premyslieť si či rozumieme špecifikácii, či je kompletná alebo či nám nechýba nejaká ďalšia informácia.
  • Ak nevieme testu vymyslieť dostatočne dobré meno (gramaticky správna veta), je možné, že očakávaná funkcionalita nepatrí do tohto komponentu, ale do niektorého vstupného parametra.
  • Ak je test príliš komplikovaný, môžeme sa zamyslieť, či sa nesnažíme testovať príliš veľa v jednom kroku, alebo či by sa komponent nemal rozdeliť na menšie časti testované nezávisle od seba.
  • Ak cyklus trval príliš dlho, tak sa môžeme zamyslieť, či robíme dostatočne malé kroky, prípadne či naozaj rozumieme riešenému problému alebo použitým technológiám.

Vieme odhadnúť kedy budeme hotoví

Prerábky existujúceho kódu sú pri TDD menej časté. Nemyslím povinný refaktoring, ale zmeny názoru ako problém riešiť. Postup je tu zvyčajne lineárny, a teda vieme odhadnúť kedy sa dostaneme do cieľa.

Debugger je zriedkavo potrebný

Kvalitné a úzko zamerané testy sú mnohokrát dobrý ukazovateľ prečo test zlyhal. Keď k tomu pridáme aktuálny kontext — tých pár riadkov, ktoré boli zmenená od posledného úspešného spustenia testov, tak je pravdepodobné, že okamžite pochopíte kde je problém. Ak aj debugger spustíte, k oprave dospejete skôr.

Pozornosť venujeme len jednej veci

Keď píšeme test, sústredíme sa na to, aby bol jasný a čitateľný. K tomu patrí rozmýšľanie o API, vstupných údajov a verifikácii výsledkov. Potom sa zase venujeme tomu, ako zabezpečiť aby produkčný kód spĺňal túto novú špecifikáciu.

Takže naša pozornosť je zameraná buď na porozumenie a zápis toho, čo chceme dosiahnuť, alebo na to ako to dosiahnuť v implementácii komponentu. Čím menej detailov potrebujeme mať na mysli v danom okamihu, tým menej sú preťažené naše kognitívne schopnosti. Keď nie sú preťažené, tak budeme viac pozorní a menej unavení.

Priebežne dostávame nápady, aké testy nám ešte chýbajú

Keď pracujeme na riešení nejakého problému, dostávame nápady čomu sa ešte treba venovať. Majme napríklad test, ktorý posiela nejaké údaje do komponentu. Pri vývoji komponentu kladieme dôraz na to, aby sme ich správne použili. Ale všimneme si, že by sa patrilo otestovať neplatné hodnoty (napr. null). Nemusíme to spraviť hneď, lebo to nesúvisí s aktuálnym problémom a ani to žiaden existujúci test nevie odchytiť. Namiesto toho, aby sme odbočili od nášho problému si len spravíme poznámku, že treba pridať test na null a prenechať stratégiu spracovania chýb na neskorší test.

Dobré pocity

Asi vás nemusím presviedčať, že máme dobrý pocit, keď vidíme ako nám pod rukami vzniká fungujúci výsledok. Čo je menej jasné je, že dobré pocity nám umožňujú pracovať efektívnejšie a poskytujú vnútornú motiváciu.

Väčšia istota pri refaktoringu

Kvalitné testy s dobrým pokrytím nám odchytia viac prípadných problémov, ktoré vzniknú pri refaktoringu. Takže keď refaktorujeme a testy nezlyhávajú, znamená to len jedno. Nič sme nepokazili. Keby sme mali nekvalitné testy, tak to ešte môže znamenať, že testom sa problém nepodarilo zachytiť.

Záver

Nie každý má pri práci na pamäti dobro projektu alebo zamestnávateľa. Ale každému by malo záležať na sebe. A teda by sa mal snažiť nájsť spôsoby práce, ktoré mu vyhovujú a prinášajú dobrý pocit a spokojnosť. Test-Driven Development je dobrý kandidát na vyskúšanie, lebo benefity ktoré prináša sú rokmi overené.

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

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

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.

React Senior Developer

Ak si React Developer, nedovoľ, aby ti uletel projekt z oblasti digitálneho bankovníctva.Ide o projekt na kontrakt s odmenou...

Java Technology Architect

Si skúsený Javista, ktorý má chuť viesť projekt digitálneho bankovníctva?Ide o prácu na kontrakt s odmenou od 5000-6000+ EUR/mesačne....

FrontEnd React.js Developer

Chceš pracovať na dlhodobom, technologicky inovatívnom projekte v oblasti prediktívneho modelovania?Pre spoločnosť, ktorá používa matematické metódy a metódy AI...

Mobile Tech Lead Developer

Máš rád svoju slobodu, pracuješ na projektoch, ideálne remote?Ide o kontrakt s odmenou 4000 - 5000+ Eur mesačne. Projekt...

Fronted Developer / Aplikácie pre diabetikov

Páčila by sa Ti zmysluplná práca na produkte - aplikácií, ktorá pomáha ľuďom s tým najcennejším, čo majú -...

Linux Admin

Pre spoločnosť, ktorá sa sa zaoberá hostingom webov a aktuálne rýchlo expanduje, hľadáme Linux Admina.Môžeš pracovať na kontrakt alebo...

Lead Developer Architect

Hľadáš istotu a stabilitu v zamestnaní? Medzinárodná spoločnosť, ktorá vyvíja finančný softvér hľadá Lead Developer Architect-a.Ide o prácu na...

.NET Bratislava Meetup #31

.NET Bratislava Meetup is a monthly meetup organized by .NET enthusiasts in Bratislava. Learn more at https://net-ba.github.io/ Meetup will...

Mária Masárová: V IT je potreba kontinuálneho vzdelávania veľmi dôležitá

Mária Masárová študuje posledný rok na VUT v Brne odbor Bioinformatika a biocomputing. Pracuje ako PHP a JavaScript developer...

Prvá LGBT+ digitálna banková platforma bola spustená v USA. Stojí za tým slovenský aktivista a EY technologický podnikateľ Matej Ftáčnik.

Daylight reaguje na finančné potreby viac ako 30 miliónov Američanov, ktorí sa hlásia k LGBT+ komunite. Táto prvá LGBT+...

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