Amintește-mi ce înseamnă "test-drive-development"?
Este o astfel de tehnică de dezvoltare software, în care toate de dezvoltare este împărțit în mai multe cicluri mai mici: primele teste scrise, care acoperă schimbarea dorită, și apoi scrie cod care trece aceste teste. Aceasta este urmată de refactorizarii cod, noi teste sunt scrise, dacă este necesar. Dacă unele teste nu transmit codul, acesta este fixat.
Pare ciudat. Și este tocmai eficient?
Aparent, da. În primul rând, vă permite să înțelegeți mai clar ce, de fapt, trebuie să scrieți. Există o condiție care trebuie îndeplinită după executarea codului - și o perioadă. Testele însele ar trebui să fie formate pe baza atribuțiilor tehnice. Dacă, ca rezultat al testelor de scriere, ele încep să se contrazică - aceasta este o ocazie de a revizui TOR.
În al doilea rând, ca urmare a repartizării sarcinilor în cel mai puțin voluminoase sarcinile secundare, codul devine mult mai simplu și mai ușor de citit. În mod ideal, un test trebuie să aibă o afirmație. În plus, cei săraci în codul de proiectare (de exemplu, folosind variabile și singletons globale) este, de obicei, la fel de dificil pentru a testa care stimulează dezvoltator nu a scris.
Dar mi se pare că scrierea ca de obicei este mult mai rapidă
Da, într-adevăr, prima utilizare a TDD va lua timp suplimentar. Cu toate acestea, este mai mult o chestiune de obișnuință - cu timpul te obișnuiești să scrie primele teste, și numai apoi codul și, probabil, va câștiga chiar și în timp, pentru că procesul de dezvoltare este clar structurat, trebuie să decidă mai întâi întrebarea: „Ce să scrie?“, Și numai atunci "Cum să scriu?". De asemenea, a lua timp acum, vei câștiga timp în viitor, va facilita în mare măsură sprijinul produsului.
Are întotdeauna sens să folosești TDD?
Bineînțeles că nu. TDD nu este un panaceu. De exemplu, în cazul în care dezvoltarea este o secvență de experimente, atunci când nu există nici o certitudine clară că este necesar, ca urmare a testului scris va fi mai marfă, care trage înapoi echipa.
