TDD

Allikas: Teadmusbaas

Test-driven development (TDD) on tarkvaraarendusprotsess, mis tugineb väga lühikese arengutsükli kordamisele: nõuded muutuvad väga spetsiifilisteks katsejuhtumiteks, seejärel parendatakse tarkvara ainult uute testide läbiviimiseks. See on vastuolus tarkvaraarendusega, mis võimaldab lisada tarkvara, mis ei vasta nõuetele.

1. Lisage test - Katsepõhises arengus algab iga uus funktsioon teema kirjutamisega. Kirjutage test, mis määratleb funktsiooni või funktsiooni täiustusi, mis peaksid olema väga lühikesed. Katse kirjutamiseks peab arendaja selgelt mõistma funktsiooni spetsifikatsiooni ja nõudeid.

2. Käitage kõik katsed ja kontrollige, kas uus test töötab - See kinnitab, et katsejuhtmed töötavad õigesti, näitab, et uus test ei liigu ilma uue koodi nõudmata, kuna nõutav käitumine on juba olemas, ja see välistab võimaluse, et uus test on vigane ja alati läbib. Uus test peaks ebaõnnestuma oodatud põhjusel.

3. Kirjuta kood - Selle sammuga tuleb kirjutada kood, mis läbib testi. Selles etapis kirjutatud kood ei pea olema täiuslik. Siinkohal on kirjaliku koodi ainus eesmärk on katse läbimine.

4. Käivitage testid. Kui kõik katsestendid läbivad, saab programmeerija kindel olla, et uus kood vastab testimisnõuetele ja ei lõhu ega lagunda olemasolevaid funktsioone.

5. Refaktori kood - Katsepõhise arendamise käigus tuleb korrapäraselt puhastada kasvav kooditabel. Uut koodi saab teisaldada kohast, kus testi sooritamiseks oli see mugav, kus see loogiliselt rohkem kuulub. Paljundamine tuleb eemaldada. Objekti, klassi, mooduli, muutuja ja meetodi nimed peaksid selgesti esindama nende praegust eesmärki ja kasutamist, kuna lisafunktsioonid lisatakse. Kuna funktsioonid on lisatud, saavad meetodikorraldused pikemaks ajaks ja muud objektid suuremaks.

6. Korda - Alustades uue uue testiga, korratakse tsüklit, et edasi liikuda.


Arendustüüp

Testid tuleb kirjutada enne testitava funktsiooni olemasolu. Sellel on väidetavalt palju eeliseid. See aitab tagada, et rakendus kirjutatakse testimiseks, sest arendajad peavad kaaluma, kuidas katsetada rakendust algusest peale selle lisamise hiljem. See tagab ka, et kõikide funktsioonide testid on kirjutatud. Lisaks sellele viiakse testide kirjutamine esmakordselt kaasa toote nõudmiste sügavamale ja varasemale mõistmisele, tagab testi koodi tõhususe ja säilitab jätkuva tähelepanu tarkvara kvaliteedile.

TDD jaoks on üksus kõige sagedamini määratletud kui klass või rühm seotud funktsioone, mida tihti nimetatakse mooduliks. On väidetavalt, et üksuste suhteliselt väikeste hoiustena pakutakse kriitilisi eeliseid, sealhulgas:

1. Vähendatud debugging jõudmine. Kui testide tõrke avastatakse, aitab väikeste üksuste kasutamine vigade jälgimisel.
2. Isesdokumenteerimise testid - Väikesed katsestendid on lihtsam lugeda ja mõista.

Allikas: [1]