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

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

Network Architect / REMOTE

Poď pracovať na projekte, ktorý zlepšuje kvalitu života pacientov prostredníctvom prelomových vedeckých objavov a inovácií. Spoločnosť pôsobí v oblasti...

Python Medior/Senior Developer

Si Python Developer a zaujíma ťa oblasť security? Pracuj podľa vlastných pravidiel, slobodne a kreatívne.Pre spoločnosť, ktorá bojuje proti...

.NET/C# Developer

Možnosť zmeniť prácu je práve teraz, hľadáme .NET/C# Developera.Práca je v nadnárodnej softvérovej spoločnosti s kanceláriou v Bratislave. Je...

.NET/PLSQL Architect

Rozmýšľaš o práci ako .NET/PLSQL Architect? Je tu možnosť na zmenu, možno hľadáme práve teba.Práca je v nadnárodnej softvérovej...

DevOps Admin / REMOTE

Už viac nechceš robiť on-site a láka Ťa homeoffice? Si DevOps Admin a hľadáš projekt do skvelým finančným ratom?Pre...

React Native Developer / REMOTE

Čo tak ukončiť rok začatím nového projektu? Tento projekt spĺňa podmienku 3R = React, Remote a dobrý Rate!Pre medzinárodnú...

Marek Barta: Chcem, aby značka bart.sk pôsobila na trhu ešte desiatky rokov.

Marek Barta, vizionár a viac dizajnér ako programátor pred 15timi rokmi založil IT spoločnosť - bart.sk. Tá...

Ako z neúspechu spraviť dôležitý medzník kariéry?

O tom prehovoria 4 odborníci z rôznorodých pracovných oblastí.

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