Blog Dokáže Test-Driven Development vyriešiť môj problém?

Dokáže Test-Driven Development vyriešiť môj problém?

Väčšina programátorov musí v práci písať unit testy. Patríte k tým, čo považujú testy za užitočné a nemajú ich problém vytvoriť? Alebo naopak, lezú vám na nervy, zavadzajú a zdržujú vás?

Ak ste v druhej skupine, možno vám táto séria článkov o Test-Driven Developmente (ďalej len TDD) pomôže nájsť lepší prístup. Mne pred rokmi TDD výrazne zlepšil môj vzťah k unit testovaniu. A vlastne aj k celému dizajnovaniu.


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


Čo je Test-Driven Development?

TDD je spôsob vývoja softvéru, pri ktorom sa opakovane vykonáva séria krátkych krokov:

  1. Červený test — naprogramujeme unit test, ktorý očakáva nejakú zatiaľ neexistujúcu funkcionalitu. Test nám hovorí, čo potrebujeme doprogramovať do komponentu. Spustíme ho a overíme, že zlyhal.
  2. Zelený test — implementujeme chýbajúcu funkcionalitu v komponente. Snažíme sa spraviť minimálne riešenie, ktoré umožní aby test prešiel.
  3. Refaktoring — ak je to možné tak odstránime nedostatky v kóde a teste, napríklad odstránime duplikovaný kód. Tento krok je dôležitejší, ako by sa mohlo zdať. Keby sme ho ignorovali, tak výsledný produkčný kód by bol mizerný.
  4. Opakuj od bodu 1 až do ukončenia. Takto postupne pridávame novú funkcionalitu a vylepšujeme kvalitu.

Týmto jednoduchým postupom vieme dosiahnuť lepšie výsledky ako pri tradičnom postupe, kde sa unit testy naprogramujú až po produkčnom kóde. Detailom, prečo je to tak sa budeme venovať v nasledujúcom článku. Jednoduchý príklad ako to prebieha v praxi pri vývoji dátovej štruktúry si môžete pozrieť v tomto článku.

TDD nežiada naprogramovanie všetkých testov dopredu, hoci si ho mnohí, čo ho nevyskúšali, takto predstavujú. Zvyčajne si ho nevyskúšali, pretože si ho predstavili práve takto. Keby sme sa pokúsili o naprogramovanie všetkých testov dopredu, je veľmi pravdepodobné, že výsledok by bol horší ako pri testoch „až po”.

Prečo to funguje?

TDD je na prvý pohľad zvláštny proces. Postavený na hlavu. 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ť.

Práve táto požiadavka, spolu s postupným striedaním písania (krátkeho) testu a prislúchajúcej implementácie je ten dôvod, prečo to funguje a prináša výhody a pohodu. V podstate nám umožňuje, aby sme sa striedavo sústredili na špecifikáciu, čo má komponent robiť; potom na to ako to má robiť a popritom ponúkať spätnú väzbu, či sme niečo pokazili alebo nie.

Zo svojich skúseností viem, že TDD funguje vynikajúco, ak sa robí správne. Situácie, kedy to nemusí fungovať dobre budú spomenuté ďalej.

Prečo ho nepoužíva každý?

Mohli by ste namietať, že keby to bol naozaj taký skvelý spôsob, tak by ho predsa používal každý. Pravda je taká, že TDD očakáva určitý systematický štýl práce a ten nevyhovuje každému.

Okrem toho, ako všetky ostatné techniky na svete, má aj svoje slabé stránky a nehodí sa na vývoj úplne všetkého. Napríklad v situácii, kedy nevieme ako máme dosiahnuť požadovanú funkcionalitu, lebo len experimentujeme s novou technológiou. Alebo nám vôbec nezáleží na kvalite.

Zoznam dôvodov, prečo práve ja na tomto projekte nemôžem použiť TDD je dlhý. Patria tam určite dôvody: ako neskúsený tím, manažment očakávajúci rýchly vývoj na úkor kvality, osobné pohodlie a neochota skúšať nové veci, pomalý vývojový cyklus, nestabilné požiadavky, ale aj mnoho ďalších. Niektoré sú skutočné a niektoré sú len výhovorky. Ja osobne nepoužívam TDD v takýchto situáciach.

Chcem si to vyskúšať. Ako mám začať?

Ak si chcete TDD vyskúšať, odporúčam počkať si na príležitosť vývoja nového komponentu. Ak tým komponentom je dátová štruktúra, tak to pôjde ľahšie, lebo má jasné vstupy a výstupy. Navyše je ľahko viditeľný rozdiel medzi testovaním čo má robiť a ako to robí. To znamená, že testovať budeme scenáre na zápis a čítanie hodnôt, namiesto overovania, či sú údaje správne uložené vo vnútornom stave komponentu.

Pozor, nepokúšajte sa o vyskúšanie TDD na starom komponente s veľkými testami. Tam by ste asi dospeli k záveru, že to nefunguje. Starý komponent si vyžaduje skúsenosti a cit pre testovateľný dizajn. Ten príde až časom.

Linky

Záver

Toto bol len úvodný článok, ktorého cieľom je predstaviť ako Test-Driven Development vyzerá. Nasledujúce články prinesú detaily o tom aké výhody TDD má a prečo. Ak ste zvedaví na praktickú ukážku TDD, prípadne si chcete o tom podiskutovať, môžete sa prihlásiť na toto školenie.


Školenie sa uskutoční 19.5.2020ONLINE o 18:00. ☞ Registrácia na š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.

Automation Tester

Máš skúsenosti s automatizovaným testovaním? Pre Automatizovaného testera máme príležitosť v oblasti digitálneho bankovníctva. Ide o projekt na kontrakt s odmenou...

Java Junior/Medior Developer

Osamostatni sa a pracuj sólo! Práve teraz je tu príležitosť pre Junior/Medior Java Developera pracovať na projekte pre medzinárodnú...

MS BI Developer / REMOTE

Sprav krok vpred s novým projektom v oblasti bankovníctva. Ide o projekt na kontrakt s dĺžkou trvania 2 roky. Odmena...

Business Development Manager

Máš skúsenosť s aktívnymi akvizíciami SW riešení pre banky/poisťovne? Pre stabilnú československú spoločnosť hľadáme Business Development Managera, ktorý sa vyzná...

Julia Developer / REMOTE

Projekt pre nadšencov Julia a machine learning. Pre spoločnosť, ktorá používa matematické metódy a metódy AI / ML na...

Scala Medior/Senior Developer

Nechceš denne dochádzať do práce? Chcel by si byť súčasťou dlhoročného startupu, len senior ľudia (žiadni študenti) a pracovať...

Junior Scala Developer

Nechceš denne dochádzať do práce? Chcel by si byť súčasťou dlhoročného startupu, len senior ľudia (žiadni študenti) a pracovať...

Toto sme stihli v roku 2020!

Rok 2020 bol určite neobyčajným rokom pre mnohých nielen z oblasti IT. Presunuli sme sa z kancelárií a open...

Tieto projekty získajú podporu z fondu SK-NIC

Poslednú tohtoročnú výzvu Fondu SK-NIC sme vyhlásili 1. septembra 2020 a otvorená bola až do 15. októbra. Do termínu uzávierky prišlo rekordných...

Novoročný AWS meetup o novinkách v cloudových technológiách

Pozývame vás na prvý AWS meetup roku 2021. Samozrejme online. Téma meetupu Každý rok prináša konferencia AWS re:Invent množstvo noviniek v...

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