Prednosti i nedostaci testiranja vođenog razvojem

Koje su prednosti i nedostaci testiranja vođenog razvojem (TDD)?

Test Driven Development je metodologija razvoja softvera kojom pišete i trčanje skup testova prije nego napišete kôd.

Ideja je da ti testovi isprva ne uspiju, a zatim počnete pisati dovoljno koda da pokušate proći sve testove. Položenje svih testova moglo bi biti mjerilo urađenih kriterija (razrađeno), a također povećava povjerenje u kvalitetu koda.

To je reklo, kao i bilo koja druga razvojna metodologija, i s TDD-om se povezuju neke prednosti i nedostaci. Ovdje ćemo navesti neke od njih, ali prije toga, najbolje je pojasniti nekoliko točaka:

• Raditi jedinstvene testove ne znači raditi TDD. Prvo možete bez drugog. U stvari, TDD možete raditi bez jedinstvenih testiranja (ali većina ljudi to čini), u ovom slučaju ljudi uglavnom nadopunjuju jedinstveno testiranje s drugim okusima testova. Ono što sigurno trebate je automatsko testiranje, kakvi god da su.
• Možete izvesti TDD za testiranje bijele kutije kako biste testirali svoj kôd. Ali TDD možete izvesti i za testiranje crnih kutija, nešto što se često naziva razvojem na temelju ponašanja.

Tradicionalno je postupak bio kodiranje puno modula, a zatim pisanje jediničnih testova za provjeru koda. Ovo je prvo kodna metoda, kasnije testirajte. Ali ako nakon kodiranja nema vremena ili ste prisiljeni na puštanje, tada se cijela vježba jedinstvenog testiranja preskače ili u najboljem slučaju radi retrospektivno.

Sada, o prednostima i nedostacima TDD-a:

Pros testova vođenog razvojem

• Budući da istodobno pišete male testove, to prisiljava vaš kôd da bude modularniji (inače bi ga bilo teško testirati). TDD vam pomaže naučiti, razumjeti i internalizirati ključne principe dobrog modularnog dizajna.
• TDD također forsira dobru arhitekturu. Da bi se vaš kod mogao testirati jedinicom, mora biti pravilno moduliran. Pisanje testova prvo, razni arhitektonski problemi obično isplivaju na površinu ranije.
• Dokumentira svoj kôd bolje od dokumentacije (ne zastarijeva jer ga stalno upotrebljavate).
• Olakšava održavanje i refaktoriranje koda. TDD pomaže u pružanju jasnoće tijekom postupka implementacije i pruža zaštitnu mrežu kada želite refaktorirati kod koji ste upravo napisali.
• Čini suradnju lakšom i učinkovitijom, članovi tima mogu međusobno uređivati ​​kod s povjerenjem jer će ih testovi obavijestiti ako promjene uzrokuju da se kod ponaša na neočekivani način.
• Budući da vas TDD u osnovi prisiljava na pisanje jediničnih testova prije pisanja implementacijskog koda, refaktoriranje koda postaje lakše i brže. Refactoring kôd napisan prije dvije godine je teško . Ako je taj kod sigurnosno kopiran nizom dobrih jediničnih testova, postupak je toliko olakšan.
• Pomaže u sprečavanju nedostataka - barem vam pomaže na samom početku pronaći probleme s dizajnom ili zahtjevima. TDD pruža rano upozorenje na probleme u dizajnu (kada ih je lakše riješiti).
• Pomaže programerima da stvarno razumiju svoj kod.
• Stvara automatizirani paket za regresijsko testiranje, u osnovi besplatno. tj. ne trebate trošiti vrijeme nakon pisanja jediničnih testova za testiranje implementacijskog koda.
• Potiče male korake i poboljšava dizajn jer vas tjera da smanjite nepotrebne ovisnosti kako biste olakšali postavljanje.
• Pomaže razjasniti zahtjeve jer morate konkretno shvatiti koje ulaze morate hraniti i koje izlaze očekujete.
• Jedinstveni testovi posebno su vrijedni kao sigurnosna mreža kada kôd treba mijenjati ili dodati nove značajke ili popraviti postojeću grešku. Budući da održavanje čini između 60 i 90% životnog ciklusa softvera, teško je prenaglasiti kako se vrijeme potrebno za stvaranje pristojnog skupa unit testova može uvijek iznova isplatiti tijekom trajanja projekta.
• Testiranje tijekom pisanja također vas prisiljava da pokušate učiniti sučelja dovoljno čistima za testiranje. Ponekad je teško vidjeti prednost ovoga dok ne radite na tijelu koda gdje to nije učinjeno, a jedini način vježbanja i fokusiranja na određeni dio koda je pokretanje cijelog sustava i postavljanje točke prekida .
• 'Glupe' pogreške hvataju se gotovo odmah. Pomaže programerima da pronađu pogreške koje bi svima potrošile vrijeme ako bi ih pronašli u QA-u.

Protiv razvoja vođenog testom

• Sam testni paket mora se održavati; testovi možda neće biti potpuno deterministički (tj. ovisni o vanjskim ovisnostima).
• Testove je možda teško napisati, posebno. izvan nivoa testiranja jedinice.
• U početku usporava razvoj; za brzo iterativna okruženja za pokretanje implementacijski kôd možda neće biti spreman neko vrijeme zbog prvoga trošenja vremena na pisanje testova. (Ali dugoročno, to zapravo ubrzava razvoj)
• Kao i svako programiranje, postoji velika razlika između toga i dobrog rada. Pisanje dobrih jediničnih testova je oblik umjetnosti. O ovom se aspektu TDD-a često ne raspravlja, mnogi se menadžeri usredotočuju na metrike poput pokrivanja koda; ti metrički podaci ne govore vam ništa o kvaliteta jediničnih testova.
• Jedinstveno testiranje nešto je za što se mora odlučiti cijeli tim.
• Izazov za učenje. To u početku može biti zastrašujuće i nije lako svima naučiti, pogotovo pokušavajući to naučiti samostalno. Zahtijeva puno predanosti (disciplina, vježbanje, ustrajnost) i morate imati cilj koji želite neprestano poboljšavati.
• Teško je primijeniti na postojeći naslijeđeni kôd.
• Mnogo zabluda zbog kojih programeri ne uče.
• Teško je početi raditi na ovaj način. Pogotovo ako mnogo godina radite na drugi način.
• Morate se ponekad rugati mnogim stvarima ili stvarima koje je teško ismijati. To je dugoročno korisno, ali trenutno bolno.
• Domaćinstvo morate obavljati kontinuirano. Budući da rezervacijom sve više i više testova vaša gradnja postaje sve duža i duža, potrebno je usavršiti te testove kako bi se brže izvodili ili ukloniti suvišne testove.
• Kao i svaka dobra tehnika, i jedinstveno testiranje može se dovesti do krajnosti. Najveće koristi proizlaze iz umjerenog napora, jer testovi uvijek izvršavaju kôd na najjednostavniji mogući način. Ako vam se često čini da faktorizirate svoje testove, velika je vjerojatnost da trošite previše vremena na testni paket.
• Može vam biti lako odvratiti pozornost od „pahuljica“ ili otmjenih značajki u okviru za testiranje jedinice. Treba imati na umu da se jednostavni testovi najbrže stvaraju i najlakše upravljaju njima.
• Iako je prijeko potrebno, stvaranje testova za kvarove može biti zamorno, ali na kraju se isplati veliko vrijeme.
• Refaktoriranje u ranoj fazi zahtijeva i ispitne satove refaktoriranja.
• Ako svi u timu ne održe ispravno svoje testove, cijeli se sustav može brzo razgraditi.