Šta je Test Driven Development, pristupi i prednosti

Test Driven Development (TDD) je pristup razvoju softvera gdje se testni slučajevi razvijaju kako bi se specificiralo i potvrdilo šta će kod učiniti.

Praktično probni slučajevi za svaku karakteristiku se kreiraju i testiraju prije objavljivanja softvera, a ako test ne uspije, novi se kod piše (ili ponovo piše ili zakrpi) kako bi prošao test i učinio kod jednostavnim i bez grešaka.

Test Driven Development (TDD) počinje sa dizajniranjem i razvojem testova za svaku malu funkciju u aplikaciji. TDD okvir upućuje programere da napišu novi kod samo ako automatizirani test nije uspio. Ovaj pristup izbjegava dupliciranje koda. Kompletan TDD modul je test-driven razvoj.

Test Driven Development (TDD) je nastao kao dio veće paradigme dizajna softvera poznate kao Extreme Programming (XP), koja je dio Agile metodologije razvoja softvera.

Jednostavan koncept TDD-a je pisanje i popravljanje neuspjelih testova prije pisanja novog koda (prije razvoja). Ovo pomaže u izbjegavanju dupliciranja koda jer pišemo malu količinu koda u isto vrijeme kako bismo prošli testove. (Testovi nisu ništa drugo do uvjeti zahtjeva koje moramo testirati da bismo ih zadovoljili).

Test-driven razvoj je proces razvoja i pokretanja automatiziranih testova prije samog razvoja aplikacije. Stoga se TDD ponekad naziva i Test First Development.

Faze TDD pristupa

Prije nego što se napiše bilo koji novi kod, programer mora prvo napraviti neuspješni jedinični test. Zatim, programer – ili par, ili mafija – kreira taman dovoljno koda da zadovolji taj zahtjev. Kada test prođe, programer može refaktorirati projekat, čineći poboljšanja bez promjene ponašanja.

Dok se TDD fokusira na interakcije programera na nivou jedinice, postoje i druge popularne metode, kao što je razvoj vođen testom prihvatanja (ATDD) ili razvoj vođen ponašanjem (BDD), koji se fokusiraju na testove koje korisnici mogu razumeti.

Ove metode uključuju izgradnju primjera iz stvarnog svijeta kao kolaborativnih testova između inženjerskog osoblja i korisnika prije kodiranja, a zatim izvođenje testova nakon kodiranja kako bi se pokazalo da je kod implementiran. Unaprijed poznati testovi poboljšavaju kvalitetu po prvi put. ATDD i BDD zahtijevaju od programera, testera i poslovne strane da rade zajedno kako bi zamislili i razgovarali o softveru i njegovim implikacijama prije kreiranja koda.

Prednosti TDD

Razvoj vođen testom može proizvesti visokokvalitetne aplikacije za manje vremena nego što je to moguće sa starijim metodama. Uspješna implementacija TDD-a zahtijeva od programera i testera da precizno predvide kako će se aplikacija i njena funkcionalnost koristiti u stvarnom svijetu.

TDD gradi paket regresijskih testova kao nuspojavu koji može minimizirati ljudsko ručno testiranje, pronalazeći probleme ranije, što dovodi do bržih rješenja. Metodička priroda TDD-a osigurava mnogo veću pokrivenost po prvi put i kvalitetu od klasičnih faznih ciklusa koda > test > popravka > ponovno testiranje. Budući da se testiranje provodi rano u ciklusu dizajna, vrijeme i novac potrošeni na kasnije otklanjanje grešaka su minimizirani.

Očekivana korist:

• značajno smanjenje u stopama kvarova, po cijenu umjerenog povećanja početnih razvojnih napora
• režijski troškovi su više nego nadoknađeni smanjenjem napora u završnim fazama projekata
• TDD dovodi do boljih kvaliteta dizajna u kodu i, općenito, višeg stupnja "internog" ili tehničkog kvaliteta, na primjer poboljšanjem kohezije i metrike spajanja

Nedostaci TDD-a

TDD zahtijeva značajnu vještinu da bi bio uspješan, posebno na nivou jedinice. Mnogi naslijeđeni sistemi jednostavno nisu izgrađeni imajući na umu testiranje jedinica, što onemogućuje izolaciju komponenti za testiranje.

Također, mnogim programerima nedostaju vještine da izoluju i kreiraju čist kod. Svi članovi tima moraju kreirati i održavati jedinične testove ili će oni brzo zastarjeti. A organizacija koja gleda na TDD moraće da uloži vreme, da malo uspori sada da bi kasnije išla brže.

Konačno, kao i kod svake metode, konačni rezultati TDD-a su dobri onoliko koliko su korišteni testovi, koliko su precizno izvedeni i u kojoj mjeri oponašaju uslove s kojima se susreću korisnici finalnog proizvoda.

Uobičajene greške:

• zaboravljajući da često izvodite testove
• napisati previše testova odjednom
• pisati testove koji su preveliki ili grubi
• pisanje previše trivijalnih testova, kao što je izostavljanje tvrdnji
• pisati testove za trivijalni kod
• djelomično usvajanje: samo nekoliko programera u radnoj grupi koristi TDD
• loše održavanje testnog paketa, što najčešće dovodi do skupa testova sa pretjerano dugim vremenom rada
• test paket napušten (tj. rijetko ili nikad ne radi) – ponekad zbog lošeg održavanja, ponekad zbog smjenjivanja tima

TDD filozofija

TDD omogućava programeru da poduzima bebe korake prilikom pisanja softvera. Test je napisan prije testiranja funkcionalnosti i osigurava da je aplikacija prikladna za testiranje. Testiranje na maloj količini koda se radi kako bi se uhvatile greške koje se javljaju u testiranom kodu. Zatim se implementira funkcionalnost. Ovo se naziva "crveno zeleni refaktor" gdje crveno označava neuspjeh, a zeleno pokazuje prolaz. Ovi koraci se zatim ponavljaju. Prvi cilj programera je da se fokusira na zadatak koji je pri ruci i da ga savlada.

Različite faze uključene u razvojni ciklus vođen testom su:

• Dodajte test: Svaka nova funkcija u TDD-u počinje testom koji mora propasti jer se postavlja prije implementacije bilo koje funkcije. Preduslov za pisanje testa prije implementacije funkcije je jasno razumijevanje zahtjeva od strane programera. To se postiže kroz korisničke priče i slučajeve upotrebe. Dakle, programer razumije zahtjev prije nego što napiše programski kod.
• Pokrenite sve testove i provjerite je li novi kod neuspješan: ovo osigurava da testni pojas radi ispravno i da novi test neće uspjeti bez novog koda. Ovaj korak također provjerava test i eliminira mogućnost da će novi test uvijek proći.
• Pisanje koda: Sljedeći korak koji slijedi je pisanje koda koji briše test. Novi kod nije savršen, ali je kasnije izmijenjen prema zahtjevima. Dizajniran je jednostavno za testiranje i nema drugih funkcija.
• Pokreni automatizirane testove: Ako svaki proizvedeni testni slučaj lako prođe test, to znači da kod ispunjava sve potrebne specifikacije. Tada se može započeti završna faza ciklusa.
• Refaktoring koda: Ovo je slično uklanjanju dupliciranja. Refaktoring ne narušava nijednu postojeću funkcionalnost i pomaže u uklanjanju dupliciranja između proizvodnog i testnog koda. Kod je sada očišćen prema zahtjevu.
• Ponavljanje: Ciklus se ponavlja kao u prethodnim slučajevima sa novim testom. Osnovni zahtjev je da je veličina koraka mala, sa oko 1-10 promjena između svakog probnog pokretanja. Ako novi kod ne prođe novi test, programer bi trebao više otklanjati greške. Kontinuirana integracija pruža reverzibilne kontrolne tačke.

Ercole Palmeri