A tesztvezérelt fejlesztés (TDD) vagya francia nyelvűtesztek által vezéreltfejlesztésekaszoftverfejlesztésegyik módszere, amely egyszoftverkis lépésekben, iteratív és növekményesmegtervezése, az egyes tesztek megírása aforráskódírása előtt,és a kód folyamatos felülvizsgálata.
Eredetileg csak a teszteket írta kódolás előtt, és a Test First Design nevet kapta . Ezután a módszer a fejlesztés finomabb részletessége felé fejlődött: egy sikertelen tesztsor esetén egy gyártósor kódot írnak, hogy a teszt sikeres legyen. A tesztkód és a gyártási kód közötti soronkénti részletesség megerősítése érdekében három törvény született.
Ezeknek a törvényeknek különböző, nagyon hasonló változatai vannak 2005 és 2008 között (2005, 2006, 2007 és 2008), amelyeket továbbra is Robert C. Martin írt: itt vannak megadva a 2008-ban használt kifejezések szerint. Azonban a " unit unit "ezekben a törvényekben itt nagyrészt zavaró. Egységteszt alapján ezek a törvények nem egy teljes tesztesetet jelölnek meg, hanem valójában egyetlen teszt állítást. A teljes tesztesetet akkor kell megszerezni, ha mindhárom törvény többszörös ismétlése megtörtént, tudva, hogy egy fordítási hiba megoldása már önmagában is iterációt jelent. 2014-ben Robert C. Martin újrafogalmazta a TDD három törvényét, és az "egységes" kifejezés eltűnik.
E három törvény pontos és egyértelmű megfogalmazása inkább a következő lenne.
Megkülönböztetünk tehát egy állítást, amely a teszt kudarcát okozta, és a tesztet, amely a végrehajtása során kudarcot vall. Ezenkívül nem feltételezzük a teszt legmegfelelőbb formáját, és nem korlátozódunk csak egy lehetséges lehetőségre, amely annál praktikusabb. Az a tény, hogy a TDD 3 törvényét egyetlen iterációval vesszük véget, a TDD nano-ciklusának nevezzük. Ne feledje, hogy ez a 3 törvény csak azokat a feltételeket fedi le, amelyeket a TDD-ben be kell tartani a sikeres teszt eléréséhez, a sikertelen teszttől elvárt minimalizmus kifejezésével.
A TDD által ajánlott folyamatnak öt szakasza van:
Ezt a folyamatot több ciklusban ismételjük, amíg az eredeti probléma teljesen megoldódik. Ezeket az iteratív fejlődési ciklusokat TDD mikrociklusoknak nevezzük.
A TDD-ben használt tesztek lehetővé teszik a szükséglet feltárását és pontosítását, majd az egyes kódolási lépések előtt meghatározzák a szoftver kívánt viselkedését a használatának megfelelően. Az így előállított szoftvert úgy tervezték, hogy pontosan kielégítse az igényeket, és úgy is, hogy ezt minimális bonyolultsággal tegye meg . Ez egy jobban megtervezett, jobban tesztelt és megbízhatóbb szoftvert, más szóval jobb minőséget eredményez.
Amikor a teszteket a kódolás után írják, amint ez hagyományosan történik, a megvalósítási lehetőségek korlátozzák a tesztek írását: a teszteket a kód szerint írják, és ha a kód egyes részei nem tesztelhetők, akkor nem is tesztelhetők. nem tesztelhető. Éppen ellenkezőleg, a kódolás előtti teszteléssel a kódot annak végrehajtása előtt használjuk, így a tesztek által meghatározott korlátok a megvalósításra vonatkoznak: a kódot a tesztek szerint írják. A tesztek TDD-kód előtti írásának ténye tehát a tesztelhető megvalósítások eredete, vagyis könnyen tesztelhető és 100% -ban tesztelhető. A kód tesztelhetősége azonban elősegíti a jobb tervezést a laza összekapcsolás és az erős kohézió révén, amely elkerüli a gyakori tervezési hibákat.
Mivel minden teszt minimális kódváltozásnak felel meg, egy teszt nyilvánvaló kapcsolatot tesz lehetővé a regresszió és a forrása között, ha nem sikerül. Ez a hivatkozás teszi a tesztek végrehajtását a TDD-ciklus sarkalatos mozzanatává: rögzítjük a szoftver pillanatnyi állapotát, és észleljük az utolsó változás utáni regressziókat. Valóban, mindenáron szeretnénk elkerülni a kód módosítását regresszió esetén. Ha igen, akkor nem lehet biztosan megmondani, hogy a sikertelen tesztek az aktuális vagy egy korábbi változásnak köszönhetők-e. Ebben jelentik a már megírt tesztek a balesetek elleni küzdelmet, ahol elveszítenék a változás és a regresszió közötti kapcsolatot. Az ilyen hámok jelenléte lehetővé teszi tehát, hogy derűsen mérlegeljük a kód bármilyen változását, legyen szó átalakításról (a viselkedést befolyásoló módosításról) vagy átszervezésről (olyan módosításról, amely nem változtatja meg a viselkedést), valamint szoftveres szállításokról. verzióról verzióra.
A ciklikus kódváltások kihívása a kódtervezés ismert igényekhez igazítása a szoftverek entrópiájának leküzdése és a technikai adósságok megakadályozása érdekében . A kód kialakításának megváltoztatása a viselkedés megváltoztatása nélkül tesztet igényel, amely biztosítja, hogy ne legyen regresszió. Ehhez különféle kiegészítő tesztformákat kell használnunk, hogy ne írjuk át őket az egyes kódok átdolgozásakor, függetlenül az átdolgozás mértékétől: néha teszteket végeznek a kezelés pontos eredményeinek igazolására, néha teszteket annak ellenőrzésére, hogy az összetevők megfelelően működnek-e. , anélkül, hogy ezek a különböző tesztek ugyanazon okok miatt szakadnának össze.
Mivel a teszteket a kódolás előtt írják meg, a TDD-ben több felhasználási lehetőséget találnak: először egy probléma megoldására szolgálnak, a kódolást végigvezetve az egyes lépéseken, majd teszteket alkalmaznak a regressziókkal szemben , végül dokumentálják a szoftver viselkedését .. Tesztjeinek köszönhetően a TDD több szempontból is megtakarítja a termelékenységet.
Amikor két ember párban jön össze egy programozási probléma megoldására, felváltva két szerepet töltenek be, hasonlóan a rally autó legénységéhez : a sofőr, aki a kulcsot, kódot tartja, míg az első tiszt felügyeli, hátralép és irányítja annak pilóta szakaszokban, majd a szerepek rendszeres időközönként cserélődnek. A TDD alkalmazásával a párok különböző módon válthatnak szerepet: akár két fejlesztési ciklus között, amikor iterálnak, vagy új sikertelen teszt írása és új viselkedés kódolása között. A szerepek cseréjének második módja arra kényszerít minket, hogy különítsük el a teszt aggályait a megvalósítás problémáitól, és a másodpilótát csak a teszt megírásához adja hozzá, míg az első lehetővé teszi egy teljes ciklus végrehajtását, miközben ugyanazt a szerepet tölti be.