Agile and Lean, Scrum, Kanban, XP @ Business

Zuzi's blog header image 2

Používáte Test Driven Development (TDD)?

19. 10. 2009 · 6 Comments

Agile

Jedním z předběžných výsledků ankety (Dotazník Jak začít pracovat Agilně (Agile Adoption Survey) 2009) který je vidět již v průběhu je, že většina lidí považuje Test Driven development (TDD) za příliš složitý na nasazení, jen čtvrtina lidí ho opravdu používá, ale skoro polovina si myslí, že je to užitečná agilní metoda. Proč tomu tak je?

Zkuste si představit třeba automobil, který by někdo vyráběl stejně, jako je píše software. Prostě by se navrhnul, poskládal dohromady, a někdo s dělníků by na půl oka zkouknul, že to vypadá jako automobil. V lepším případě by motor vypadl až někde cestou, dveře by nešly zevnitř otevřít a nádrž na benzín by byla shodou náhod hermeticky uzavřená. O bezpečnosti jízdy ani nemluvě.

Než takový automobil pustíte na silnici…
picture1

nejdříve připravíte testy, třeba tento:
připravit testy

pak testy spustíte…
sputit testy

a teprve když jsou všechny v pořádku, dáte auto zákazníkovi…
hotový výrobek

Takže proč když to můžeme dělat při výrobě automobilu, neděláme to při výrobě software? Myslím, že je to jen zvyk. U softwaru totiž většinou nic moc nehrozí. To že programy nefungují, už jsme si přeci zvykli.

Ale i tak, Test Driven Development (TDD) rozhodně stojí za zamyšlení. Odhlédneme-li od spokojenosti zákazníka, je tu i spousta interních aspektů. Např. máte-li kód plně automaticky testován, snižujete riziko refactoringu a případné chyby, které způsobíte v jiných částech aplikace, najdete hned a sami. A na tom že každý systém jednou potřebuje třeba jen drobný refactoring se asi shodneme. Myslím, že investice do testů na začátku se Vám vrátí velmi brzy.

Proč to tedy nezkusit… Mimochodem, víte, jak se pozná, že už jste opravdu v Test Driven Developmet světě? Než upravíte nějakou funkcionalitu, nejdříve ‘rozbijete‘ test (tedy upravíte ho podle nových požadavků, a spustíte) a teprve až test neprojde, opravíte funkcionalitu tak, aby všechny testy byly v pořádku. Je to jiné, zdá se to být zvláštní, ale funguje to.

 


Zuzana Šochová - The Great ScrumMaster:#ScrumMasterWayNaučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay nebo Agilní Metody Řízení Projektů.


 

Tags: ·

6 responses so far ↓

  • 1 Satai // Oct 20, 2009 at 8:10 am

    Neni nic vic zavadejiciho, nez paralely mezi fyzickym a informatickym svetem ;)

    Btw: ten motivacni priklad “vysvetluje” vyhody testovani, ale motivace k TDD by musela nejspis byt argumentacne o neco subtilnejsi ;)

  • 2 Guido // Oct 20, 2009 at 8:59 am

    “máte-li kód plně automaticky testován, snižujete riziko refactoringu”

    Chápu to špatně, že refactoring je uváděn jako riziko?!? Refactoring je snad (téměř) vždy přínosem a věc žádaná, ne?

    Ten článek mi přijde ne úplně domyšlený (nebo špatně formulovaný). Má to být o (ne)používání TDD, nebo o absenci testů? To se přece nevylučuje.

  • 3 karmi // Oct 27, 2009 at 4:24 pm

    Osvěta ohledně TDD je výborná věc, ale ono pozor s tím :) Např. podle ne-úplně-neznámého-pána-co-se-TDD-týče, Warda Cunninghama: „Test-first coding is not a testing technique.“ [http://data.karmi.cz/varia/microsoft-tdd/Slides.TDD.Microsoft.html#3]

    Zní to divně? Možná. Ale TDD je daleko více o *designu* (nebo chcete-li „architektuře“) než o „testování“. TDD je v tomto smyslu doopravdy „složitý“ na nasazení, protože odporuje představě, že se tak dlouho něco ťuká a něco kliká, až to jakž takž funguje.

    Vytvářet software doopravdy agilně bez testů (které ani nemusí být „written first“) téměř nejde — protože největším nepřítelem „agility“ je *strach ze změny*.

  • 4 zuzi // Oct 27, 2009 at 4:46 pm

    Zdravim,
    refactoring znamena praci navic, obvykle proto, ze se zmenily pozadavky. Pak je jiste prinosem, neb jine pozadavky neni mozne ignorovat :) Rizikem refactoringu je ze pri nem nevedomky rozbijete jiny kod aniz o tom vite ….

    Proc testovat je jedna vec, jak testovat je druha. Uzce spolu souvisi…

    Zuzi

  • 5 Oleg // Nov 7, 2009 at 10:35 am

    Ahoj.

    “A kdo to zaplati?” To nejcasteji slycham pri diskuzich o testovani… Jedine, co na to umim odpovedet je, ze je otazka, co stoji vic – testovani nebo nasledna oprava chyb.

    Oleg

  • 6 Lubos // Nov 30, 2009 at 11:39 pm

    … ja souhlasim ze TDD je bliz k designu i kdyz nazvem napovida neco jineho. Nejlepsi prirovnani je podle me dvojice XML a XSD, XSD jako design template