A TDD-ről (Test Driven Development) még a BME-n írtam Szoftverminőség és menedzsment tárgy kereteiben, és bár tetszett az ötlet, de nem igazán tudtam elképzelni öt éve, hogy hogy lehetne egy alkalmazást fullosan tesztelhetővé tenni, vagy úgy megírni.
2010-ben egy korábbi munkahelyemen, ahol azért elég pro arcokat válogattak össze, még mindig ott tartottunk, hogy invesztigálni kellene a TDD-t, hogy mire jutnánk vele.
2011-ben amikor a Sanoma Mediánál voltam a PPCS (Product Price Comparison System) / Olcsóbbat / Kirakat projekten, egy több hetes hibakeresésre sikerült pontot tenni azzal hogy - az amúgy korábbról teljesen teszteletlen kódhoz - felraktam egy PHPUnitot és írtam pár unit tesztet, egyből (egy napon belül) kibuktak a bugok. Ekkor kezdtem ténylegesen hinni a unit tesztelésben.
2012-ben alkalmam nyílt részt venni az Emarsysnál egy igen nagy folyamatos fejlesztő / refaktor projektben, ami teljesen megváltoztatta a Test Driven Developmentről kialakult képet a fejemben, mivel végre láttam hogy hogy is lehet ezt fulltime alkalmazni, hogy lehet valamit 100% TDD-vel megírni.
A módszernek láttam előnyeit és hátrányait, és biztos vagyok benne, hogy vannak helyzetek, amikor alkalmaznám. Alapvetően feladatfüggőnek gondolom. Ha sok pénz múlik azon, hogy a kiadott termék hibamentes legyen (pl. mert egy olyan piaci szegmensben játszol, ahol a bugok egyszerűen nem tolerálhatóak, a vevők odébb mennek), akkor mindenképp érdemes lehet használni.
