Mitä on testivetoinen kehitys? Tai TDD?
Testausvetoinen kehitys tai TDD, kuten se kehityskumppaneissa tunnetaan, on tärkeä osa ohjelmistokehitysprosessia. Tämän lähestymistavan avulla on helpompaa testata, mitä tietty koodi toimisi. Ohjelmistosovelluksen jokaista toimintoa varten luodaan testitapauksia, ja jos jokin toiminto epäonnistuu testissä, koodi käsitellään uudelleen ja luodaan uusia koodeja. Uuden koodin pitäisi myös läpäistä testi ja olla virheetön. Kehittäjän on kirjoitettava uusi koodi vain, jos koodin automaattinen testi on epäonnistunut, joten jokaiselle toiminnolle, olipa se kuinka pieni tahansa, on testitapaus. Ja TDD: ssä on kyse testien suunnittelusta ja kehittämisestä sovelluksen jokaiselle toiminnalle.
Nimi Test Driven Development osoittaa, että testien tekeminen oikealla tavalla ohjaa ohjelmistokehitystä. Siksi itse prosessi juontaa juurensa ketterästä metodologiasta ja äärimmäisestä ohjelmoinnista. Tämä prosessi varmistaa, että kehittäjät luovat ja ylläpitävät joustavaa ja pitkäaikaista koodia.
Joten TDD -prosessi olisi kirjoittaa yksikkötesti ensin ja jos testi epäonnistuu, sitten koodimuutokset toteutetaan. Tämä auttaa välttämään myös koodin päällekkäisyyttä. Koko asia perustuu epäonnistuneiden testien kirjoittamiseen ja korjaamiseen ennen varsinaista kehitystä. Kuitenkin, jotta TDD toimisi onnistuneesti, olisi suositeltavaa kirjoittaa testitapaukset yksinkertaisiin testitapauksiin. Monimutkaisen liiketoimintalogiikan vuoksi olisi todella vaikeaa kirjoittaa testitapausten yhdistelmä ja saavuttaa täysi menestys. On mahdollista, että menetät joidenkin testien kirjoittamisen, joten se ei ole ollenkaan helppoa.
Ero TDD: n ja perinteisen testauksen välillä
Perinteinen testaus vie enemmän aikaa kuin TDD, ja se perustuu lyhyen kehityssyklin toistamiseen. Ensin testi kirjoitetaan alusta, sitten ohjelmakoodi ja sitten haluttu järjestelmän toiminta. Kun kirjallinen koe läpäistään (tarkistetaan kirjoittamattoman koodin työn oikeellisuus), kirjoitettu koodi suoritetaan uudelleen.
Aluksi TDD on myös aikaa vievä, mutta ajan myötä kehittäjä tottuu siihen, koska kehitysprosessi tulee rakenteellisemmaksi. Esimerkiksi kun palkkaat kehittäjän, hän päättää mitä kirjoittaa ja sitten miten kirjoittaa.
Perinteinen testaus onnistuu, kun se löytää oikein yhden tai useamman vian. Aivan sama kuin TDD. Vikojen löytäminen on itse asiassa hyvä merkki, koska silloin tiedät, että sinun on ratkaistava vika ja siirryttävä siitä eteenpäin. TDD antaa sinulle myös enemmän luottamusta, kun julkaiset ohjelman, ja varmistaa, että se täyttää vaatimukset, joita varten se on määritelty.
Perinteisessä testauksessa keskitytään enemmän testikotelon suunnitteluun, kun taas TDD: ssä keskitytään enemmän tuotantokoodiin sen varmistamiseksi, toimiiko testaus suunnitellusti.
TDD tarjoaa sinulle 100% testin kattavuuden, jossa testaus tehdään jokaiselle koodiriville, näin ei ole perinteisen testauksen tapauksessa.
Kun projektin laajuus on todella suuri, sinun on oltava todella perusteellinen testejä suoritettaessa. On myös mahdollista, että testaus viivästyy ja ylittää budjetin ja aikarajoitukset.
TDD: tä voi olla vaikea kirjoittaa, ja se saattaa hidastaa kehitysaikaa, mutta se varmasti kannattaa pitkällä aikavälillä.
Toinen TDD: n haittapuoli on, että konseptia on vaikea soveltaa olemassa olevaan vanhaan koodiin.
On aina hyvä, että testi epäonnistuu ennen projektin julkaisemista, koska silloin tiedät suorittaneesi kelvollisen testin. TDD: n kautta tiedät, että järjestelmäsi täyttää vaatimukset, joita varten se on suunniteltu. Joten keskitytään enemmän TDD: n tuotantokoodiin, koska se varmistaa, toimiiko testaus oikein. Ja kun ohjelmisto täyttää kaikki sille suunnitellut vaatimukset.
Testivetoisen kehityksen eri vaiheet
TDD: ssä on kolme eri vaihetta: punainen, vihreä ja refactor
Noudattamalla tätä vaiheiden järjestystä varmistat, että sinulla on testejä kirjoittamaasi koodiin, joten sinun on kirjoitettava koodit vain niille testeille, joita teet.
Punainen vaihe
Punaisen vaiheen ajatuksena on saada testi epäonnistumaan ja myös vaikein vaihe, koska kehitystyön on kirjoitettava testi ilman koodia. Uusien kehittäjien on pidettävä sitä vaikeana, koska he olisivat hämmentyneitä siitä, mitä testata ilman koodia. Mutta se on tavanomainen asia ja kokemuksen myötä siitä tulee sujuvaa. Ensimmäinen testi kirjoitetaan kirjoittamatta koodia ja ilmoittaa luokka ja menetelmä, ja testissä on kokoamisvirhe. Seuraava askel olisi korjata kokoamisvirhe ja suorittaa testi epäonnistuaksesi. Tämä aiheuttaa punaisen lipun.
Vihreä vaihe
Punaisen vaiheen jälkeen seuraava vaihe olisi koodin kirjoittaminen. Tämän koodin on läpäistävä ensimmäinen testi. Pelkkä koodin kirjoittaminen sen varmistamiseksi, että vain ensimmäinen testi läpäisee, on este, jonka monet kehittäjät kohtaavat aluksi. Koska seuraavassa testissä sen pitäisi epäonnistua ja sen jälkeen uusi koodi niiden läpäisemiseksi.
Refraktorin vaihe
Kahdessa ensimmäisessä vaiheessa, joissa testin on ensin epäonnistuttava ja sitten läpäistävä, tavoitteena oli saada testit läpäistäviksi. Mutta Refractor -vaiheessa on otettava huomioon muita tekijöitä, kuten koodin laatu, koodin ylläpidettävyys, koodin luettavuus jne. Tässä keskitytään siis näihin näkökohtiin, joten yksikkötestit keskittyvät niihin. Refactoring -vaiheessa sinun ei tarvitse huolehtia puuttuvasta toiminnallisuudesta, koska kun koodimuutokset tapahtuvat, testitapaukset vastaavat automaattisesti myös toiminnallisuusosaa.
TDD sopii hyvin ketterään menetelmään
On aivan selvää, että projektivaatimukset voivat muuttua pitkälle kehitysvaiheeseen, joten TDD: n saaminen yhteistyössä ketterän kehityksen kanssa tekee siitä varmasti menestyvän ja rakentaa projekteja asiakkaiden vaatimusten mukaisesti. Testipohjaisen kehityksen avulla saat aikaisemman palautteen projektista, jonka kanssa voit helposti työskennellä.
Se auttaisi myös ennakoimaan ja vähentämään kriittisiä pullonkauloja ja varmistaa, että projekti etenee suunnitellusti. Kehittäjätiimit voivat säästää paljon aikaa, koska testit luodaan paljon aikaisemmin projektin kehitysvaiheessa, eikä heidän tarvitse huolehtia laajoista testikomentosarjoista.
Johtopäätös
Testipohjainen kehitys on tekniikka, joka todellakin vie aikaa, mutta on arvokas siinä mielessä, että se auttaa ohjaamaan projektiasi oikeaan suuntaan saamalla oikeaa palautetta projektista ja havaitsemalla vikoja. Se on kuitenkin paljon parempi vaihtoehto kuin perinteinen testaus, koska se vaatii enemmän aikaa ja rahaa.
Mielenkiintoisia linkkejä:
Testivetoinen kehitys: mikä se on ja mikä ei.
Lisätietoja testipohjaisesta kehityksestä
Kuvat: Canva
Kirjoittaja: Sascha Thattil työskentelee Software-Developer-India.com -sivustolla, joka on osa YUHIRO-ryhmää. YUHIRO on intialainen saksalainen yritys, joka tarjoaa ohjelmoijia IT-yrityksille, virastoille ja IT-osastoille.
Vastaa