Miért kellene kezdeni, hogy végezzen teszt-vezérelt fejlesztés
Emlékeztesd őket, hogy ez az egész a te «Test-Drive-fejlesztés»?
Ez egy olyan szoftverfejlesztési technika, amelynek során valamennyi fejlesztési van osztva több kisebb ciklusok: első írásos tesztek, ami fedezi a kívánt változást, majd írjuk kódot, hogy átadja ezeket a teszteket. Ezt követi a kód újraírás, új vizsgálatok vannak írva, ha szükséges. Ha bármilyen vizsgálatot darab kód nem ez jobb.
Úgy hangzik, mint egy furcsa módon. És ez pontosan hatékony?
Úgy tűnik, igen. Először is, ez lehetővé teszi, hogy jobban megértse, hogy pontosan mit kell írni. Van egy feltétellel, hogy el kell végezni munka után kód - és ez a lényeg. Tesztek maguk kell kialakítani alapján feladatmeghatározás. Ha ennek eredményeként az írás teszt kezdenek ellentmondanak egymásnak - ez egy olyan alkalom, hogy vizsgálja felül a TOR.
Másodszor, ennek eredményeként a feladatmegosztás a legkevésbé terjedelmes részfeladatok, a kód lesz sokkal egyszerűbb és olvashatóbb. Ideális esetben az egyik kell tesztelni egy állítás (assert). Ezen túlmenően, a szegények, a tervezési kód (például a globális változók és singletons) általában ugyanolyan nehéz tesztelni, amely stimulálja a fejlesztő nem írni.
De nekem úgy tűnik, hogy a levelet a szokásos módon sokkal gyorsabban
Igen, valóban, az első használat TDD lesz hosszabbítás. Azonban ez inkább megszokásból - idővel megszokja, hogy írjon az első tesztek, és csak ezután a kódot, és talán lesz még nyerni, mert a fejlesztési folyamat világosan strukturált, akkor először eldönteni a kérdést: „Mit kell írni?”, És csak ezután „Hogyan írjunk?”. Továbbá, hogy időt, most, akkor időt lehet nyerni a jövőben, nagyban megkönnyíti a támogatást a termék.
Mindig van értelme használni TDD?
Természetesen nem. TDD nem csodaszer. Például, ha a fejlesztés sorozata kísérletek, ha nincs egyértelmű biztos, hogy szükség van ennek következtében az írás teszt lesz több rakomány, amely húzza vissza a csapat.
