Došlo e-mailem:

Jak vnímáte TDD dva a půl roku po napsání tohoto blogu? Ještě stále TDD, nebo už je pro Vás tato metodika mrtvá? Pokud stále žije, popasoval jste se s tím, jak ji napasovat na projekt, který s něčím takovým od základu nepočítá, ale naopak kupí všechny známé programátorské chyby na jednu hromadu?

Jde o to, že momentálně se potýkám s tímtéž – rád bych ve firmě zavedl TDD jako oficiální metodiku, ale praktická zkušenost chybí a stejně tak chybí i znalost, jak to napasovat právě na ty “nemocné” projekty, kde je toho paradoxně nejvíce zapotřebí.

Email odkazuje na následující článek: http://dejv.eu/15-vyhody-tdd/

TDD stále využívám. Hlavně v dynamických jazycích se jedná o nepostradatelný nástroj. U těchto jazyků se automatické testování hodí i při deploymentu. Například u projektů napsaných v Ruby hned poznám jestli jsou nainstalovány všechny knihovny a skripty jsou kompatibilní se systémem na serveru.

U starších projektů je to složitější. Starám se o jednu rozsáhlou CRUD aplikaci napsanou špagetovým stylem, kdy metody komponent pouze volají jiné komponenty. V tomto případě je využití TDD dosti náročné, jelikož většina úkolů spočívá v modifikaci takto napsaného kódu, který sám od sebe nelze jednoduše vyjmout. Dvojnásobně to platí pro projekty jejichž IDE postrádají jakékoliv nástroje pro automatický refactoring.  Jednou z možností by byla investice do přepsání, alespoň, hlavních modulů.

U lépe napsaných projektů by to mohlo jít i za pochodu. Sám jsem jeden takový měl a zavedl jsem pravidlo kdy opravení každé chyby vyžadovalo napsání příslušného testu. Pokrytí testů bylo sice velmi mizivé, ale během krátké doby zasahovalo nejproblémovější části aplikace.