A TDD (Test Driven Development) világa, II. rész: Gyakori tévhitek
A sorozat előző részében egy kis bevezetést adtunk a témához, most pedig a TDD-t övező gyakori tévhitekkel folytatjuk, amelyek tisztázása talán segít abban, hogy magabiztosabban vessük bele magunkat a TDD sűrűjébe.
1. tévhit: A unit tesztek fő feladata a kód helyességének ellenőrzése
A valóságban a szoftvertesztelés különböző fajtái csak nagyon kevés bugot képesek felfedni (kb. a hibák 20%-át). Összevetve ezt az automatizált teszteléshez szükséges plusz munkával, eléggé kérdéses lenne annak megtérülése.
Az igazság ezzel szemben az, hogy az automatizált unit tesztek és a TDD elsődleges célja a refaktorálás elősegítése. Ha minden időpillanatban egyetlen gombnyomással ellenőrizhetjük, hogy a funkcionalitás még mindig ugyanazt csinálja, mint eddig, bátran átrendezhetjük a kódot ahogy jónak látjuk. Ide kapcsolódóan érdemes még megjegyezni, hogy a "unit" szó itt nem elsősorban egy kódbeli egységet jelöl (pl. egy metódust), hanem egy funkcionális egységet. Ez gyakran összevág, de egyáltalán nem mindig.
2. tévhit: A TDD elhanyagolja a tervezést, hiszen az első lépésben nem kell törődnünk a kódminőséggel, a lényeg, hogy átmenjen a teszt
A TDD egyáltalán nem mismásolja el a tervezést, ha a "Red. Green. Refactor." filozófiának nem hanyagoljuk el a "Refactor" részét. Csupán arról van szó, hogy ez a filozófia "szétkeni" a folyamatot az egész fejlesztési ciklusra, nem igényli azt, hogy a szoftverünk egészét pontosan előre specifikáljuk (ami általában amúgy is problémás).
3. tévhit: A TDD-ben minden egyes osztályt és metódust tesztekkel kell ellenőrizni
Ezt már érintettem az első pontban is, de érdemes itt is megismételni. Ez az állítás már csak azért sem lehet igaz, mert a refaktorálás fázisában nem szabad új teszteket írni, így ha esetleg ott valamit új metódusokba vagy osztályokba szervezünk át, ahhoz nem fognak tesztek tartozni. Ezzel szemben a tesztek alanya leginkább egy-egy osztály/API publikus interfésze, és a központban a viselkedés van, nem pedig az implementáció. Ennek megvan az a hasznos mellékhatása is, hogy a fejlesztők hajlamosak lesznek könnyen implementálható interfészek helyett jól használhatóakat kialakítani.
4. tévhit: "Nem tudok előre teszteket írni, mert még nincs egy átfogó képem a készítendő programról"
Természetesen minden tesztet előre megírni pontosan ugyanazokat a hátrányokat hordozná, mint részletes specifikációt készíteni az egész szoftverről még az első kódsor megírása előtt. Mivel utóbbit egyáltalán nem szeretnénk, így az előbbit sem tarthatjuk jónak, és nem is erről van szó.
A zavar itt elsősorban a unit testing és az acceptance testing fogalmak keveréséből adódik. Az utóbbihoz valóban rendelkeznünk egy pontos képpel arról, hogy a rendszerünk egésze mit csinál pontosan, de senki sem kéri, hogy ezt előre készítsük el. A unit tesztek jellegzetessége pontosan az, hogy maguknak a teszteknek nincs tudomásuk a szoftver felépítéséről, az egységeket izoláltan teszteljük. (Ez igényel néhány speciális technikát, erről a következő részben ejtünk szót).
5. tévhit: Ha TDD-t használok, nincs szükség további tesztelésre
Ez már a ló túlsó oldala, és természetesen köze sincs az igazsághoz, nem is állít ilyet senki. Az előbbiekben láttuk, hogy a TDD elsősorban nem a tesztelés eszköze, és egy agilis szoftverfejlesztő szervezetben a TDD nem is a QA csapat hatáskörébe tartozik. A TDD ebből a szempontból csupán egy hasznos kiegészítő eszköz a teljes tesztelési stratégiát tekintve, azonban elengedhetetlen számos más agilis tesztelési módszertan alkalmazása.
Ezzel a néhány ponttal remélhetőleg sikerült eloszlatni néhány, a TDD-t övező a tévhitet — a következő részben konkrét példákkal és technikákkal folytatjuk.