Príklad na TDD (Test-Driven Development) v tomto článku bol príliš jednoduchý. TDD si zaslúži komplikovanejší a dlhší príklad. Tentokrát postup nebudem vysvetľovať tak podrobne, takže ak nemáte s TDD skúsenosti, prečítajte si najprv ten starší článok.
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
Boli časy, keď ma dizajn aplikácie vedel pekne vytrápiť. Mohlo to byť aj nedostatkom skúseností, ale väčšiu rolu zohralo to, že som ho vymýšľal dopredu a bol som zahltený množstvom detailov.
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
Predpokladám, že väčšine z vás napadlo, že vo vašom prípade, sa Test-Driven Development nedá použiť. Čiastočne máte pravdu. TDD, ako všetko ostatné na svete, má svoje výhody a nevýhody. Má svoje silné stránky a aj slabé. V tomto článku sa chcem venovať situáciam, kedy TDD nie je najvhodnejší nástroj.
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
Bežným nedorozumením pri Test-Driven Development (TDD) je, že všetky testy pre vyvíjanú triedu treba napísať dopredu — skôr ako sa začne implementovať samotná funkcionalita. A prípadne tie testy môže vytvoriť niekto skúsenejší a implementáciu prenechá juniorovi. Takúto predstavu majú aj niektorí skúsení „unit testovači”, a preto sa im „TDD” nepáči. Týmto článkom by som chcel vysvetliť prečo je snaha o napísanie všetkých textov dopredu nesprávna. Teda, podľa mňa je nesprávna. Niekomu to možno funguje a je spokojný (poprosím vás o komentár).
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
Každý dobre vie, že testy máme na to, aby sme vedeli, či aplikácia funguje. Teda musia byť stále zelené. A keď nejaký test očervenie, tak máme problém. Treba ho opraviť. (Aspoň dúfam, že ste na vašom projekte nerezignovali a nezačali ignorovať zlyhávajúce testy.)
Tak prečo máme pri Test-Driven Developmente (TDD) povinnosť skontrolovať, že je test na začiatku červený? No predsa, aby sme vedeli, že niečo testuje.
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
V tomto článku vám podrobne vysvetlím jednotlivé kroky požadované pri používaní metodológie Test-Driven Development (TDD).
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
Tento článok je úmyselne krátky, lebo chcem aby fungoval ako referencia. Takto sa k nemu môžete vrátiť neskôr a pripomenúť si jednotlivé kroky. Z toho dôvodu v ňom nechcem ísť do detailov. Na to bude priestor v nasledujúcich článkoch.
Vývoj komponentu podľa Test-Driven Development (TDD) sa skladá z opakovania krátkej sekvencie krokov. Zjednodušene to vyzerá takto:
Pozrime na jednotlivé kroky.
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”