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…
nejdříve připravíte testy, třeba tento:
pak testy spustíte…
a teprve když jsou všechny v pořádku, dáte auto zákazníkovi…
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.
Nauč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, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
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 😉
“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.
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*.
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
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
… 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