{"id":21410,"date":"2021-08-27T10:54:53","date_gmt":"2021-08-27T08:54:53","guid":{"rendered":"https:\/\/www.software-developer-india.com\/mita-on-testivetoinen-kehitys-tai-tdd\/"},"modified":"2021-08-27T10:55:01","modified_gmt":"2021-08-27T08:55:01","slug":"mita-on-testivetoinen-kehitys-tai-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/fi\/mita-on-testivetoinen-kehitys-tai-tdd\/","title":{"rendered":"Mit\u00e4 on testivetoinen kehitys? Tai TDD?"},"content":{"rendered":"\n

Mit\u00e4 on testivetoinen kehitys? Tai TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Testausvetoinen kehitys tai TDD, kuten se kehityskumppaneissa tunnetaan, on t\u00e4rke\u00e4 osa ohjelmistokehitysprosessia. T\u00e4m\u00e4n l\u00e4hestymistavan avulla on helpompaa testata, mit\u00e4 tietty koodi toimisi. Ohjelmistosovelluksen jokaista toimintoa varten luodaan testitapauksia, ja jos jokin toiminto ep\u00e4onnistuu testiss\u00e4, koodi k\u00e4sitell\u00e4\u00e4n uudelleen ja luodaan uusia koodeja. Uuden koodin pit\u00e4isi my\u00f6s l\u00e4p\u00e4ist\u00e4 testi ja olla virheet\u00f6n. Kehitt\u00e4j\u00e4n on kirjoitettava uusi koodi vain, jos koodin automaattinen testi on ep\u00e4onnistunut, joten jokaiselle toiminnolle, olipa se kuinka pieni tahansa, on testitapaus. Ja TDD: ss\u00e4 on kyse testien suunnittelusta ja kehitt\u00e4misest\u00e4 sovelluksen jokaiselle toiminnalle. <\/p>\n\n

Nimi Test Driven Development osoittaa, ett\u00e4 testien tekeminen oikealla tavalla ohjaa ohjelmistokehityst\u00e4. Siksi itse prosessi juontaa juurensa ketter\u00e4st\u00e4 metodologiasta ja \u00e4\u00e4rimm\u00e4isest\u00e4 ohjelmoinnista. T\u00e4m\u00e4 prosessi varmistaa, ett\u00e4 kehitt\u00e4j\u00e4t luovat ja yll\u00e4pit\u00e4v\u00e4t joustavaa ja pitk\u00e4aikaista koodia. <\/p>\n\n

Joten TDD -prosessi olisi kirjoittaa yksikk\u00f6testi ensin ja jos testi ep\u00e4onnistuu, sitten koodimuutokset toteutetaan. T\u00e4m\u00e4 auttaa v\u00e4ltt\u00e4m\u00e4\u00e4n my\u00f6s koodin p\u00e4\u00e4llekk\u00e4isyytt\u00e4. Koko asia perustuu ep\u00e4onnistuneiden testien kirjoittamiseen ja korjaamiseen ennen varsinaista kehityst\u00e4. Kuitenkin, jotta TDD toimisi onnistuneesti, olisi suositeltavaa kirjoittaa testitapaukset yksinkertaisiin testitapauksiin. Monimutkaisen liiketoimintalogiikan vuoksi olisi todella vaikeaa kirjoittaa testitapausten yhdistelm\u00e4 ja saavuttaa t\u00e4ysi menestys. On mahdollista, ett\u00e4 menet\u00e4t joidenkin testien kirjoittamisen, joten se ei ole ollenkaan helppoa. <\/p>\n\n

Ero TDD: n ja perinteisen testauksen v\u00e4lill\u00e4<\/strong><\/h3>\n\n

Perinteinen testaus vie enemm\u00e4n aikaa kuin TDD, ja se perustuu lyhyen kehityssyklin toistamiseen. Ensin testi kirjoitetaan alusta, sitten ohjelmakoodi ja sitten haluttu j\u00e4rjestelm\u00e4n toiminta. Kun kirjallinen koe l\u00e4p\u00e4ist\u00e4\u00e4n (tarkistetaan kirjoittamattoman koodin ty\u00f6n oikeellisuus), kirjoitettu koodi suoritetaan uudelleen. <\/p>\n\n

Aluksi TDD on my\u00f6s aikaa viev\u00e4, mutta ajan my\u00f6t\u00e4 kehitt\u00e4j\u00e4 tottuu siihen, koska kehitysprosessi tulee rakenteellisemmaksi. Esimerkiksi kun palkkaat kehitt\u00e4j\u00e4n, h\u00e4n p\u00e4\u00e4tt\u00e4\u00e4 mit\u00e4 kirjoittaa ja sitten miten kirjoittaa. <\/p>\n\n

Perinteinen testaus onnistuu, kun se l\u00f6yt\u00e4\u00e4 oikein yhden tai useamman vian. Aivan sama kuin TDD. Vikojen l\u00f6yt\u00e4minen on itse asiassa hyv\u00e4 merkki, koska silloin tied\u00e4t, ett\u00e4 sinun on ratkaistava vika ja siirrytt\u00e4v\u00e4 siit\u00e4 eteenp\u00e4in. TDD antaa sinulle my\u00f6s enemm\u00e4n luottamusta, kun julkaiset ohjelman, ja varmistaa, ett\u00e4 se t\u00e4ytt\u00e4\u00e4 vaatimukset, joita varten se on m\u00e4\u00e4ritelty. <\/p>\n\n

Perinteisess\u00e4 testauksessa keskityt\u00e4\u00e4n enemm\u00e4n testikotelon suunnitteluun, kun taas TDD: ss\u00e4 keskityt\u00e4\u00e4n enemm\u00e4n tuotantokoodiin sen varmistamiseksi, toimiiko testaus suunnitellusti. <\/p>\n\n

TDD tarjoaa sinulle 100% testin kattavuuden, jossa testaus tehd\u00e4\u00e4n jokaiselle koodiriville, n\u00e4in ei ole perinteisen testauksen tapauksessa.<\/p>\n\n

Kun projektin laajuus on todella suuri, sinun on oltava todella perusteellinen testej\u00e4 suoritettaessa. On my\u00f6s mahdollista, ett\u00e4 testaus viiv\u00e4styy ja ylitt\u00e4\u00e4 budjetin ja aikarajoitukset. <\/p>\n\n

TDD: t\u00e4 voi olla vaikea kirjoittaa, ja se saattaa hidastaa kehitysaikaa, mutta se varmasti kannattaa pitk\u00e4ll\u00e4 aikav\u00e4lill\u00e4. <\/p>\n\n

Toinen TDD: n haittapuoli on, ett\u00e4 konseptia on vaikea soveltaa olemassa olevaan vanhaan koodiin. <\/p>\n\n

On aina hyv\u00e4, ett\u00e4 testi ep\u00e4onnistuu ennen projektin julkaisemista, koska silloin tied\u00e4t suorittaneesi kelvollisen testin. TDD: n kautta tied\u00e4t, ett\u00e4 j\u00e4rjestelm\u00e4si t\u00e4ytt\u00e4\u00e4 vaatimukset, joita varten se on suunniteltu. Joten keskityt\u00e4\u00e4n enemm\u00e4n TDD: n tuotantokoodiin, koska se varmistaa, toimiiko testaus oikein. Ja kun ohjelmisto t\u00e4ytt\u00e4\u00e4 kaikki sille suunnitellut vaatimukset.<\/p>\n\n

Testivetoisen kehityksen eri vaiheet<\/strong><\/h3>\n\n

TDD: ss\u00e4 on kolme eri vaihetta: punainen, vihre\u00e4 ja refactor<\/p>\n\n

Noudattamalla t\u00e4t\u00e4 vaiheiden j\u00e4rjestyst\u00e4 varmistat, ett\u00e4 sinulla on testej\u00e4 kirjoittamaasi koodiin, joten sinun on kirjoitettava koodit vain niille testeille, joita teet. <\/p>\n\n

Punainen vaihe<\/strong><\/h3>\n\n

Punaisen vaiheen ajatuksena on saada testi ep\u00e4onnistumaan ja my\u00f6s vaikein vaihe, koska kehitysty\u00f6n on kirjoitettava testi ilman koodia. Uusien kehitt\u00e4jien on pidett\u00e4v\u00e4 sit\u00e4 vaikeana, koska he olisivat h\u00e4mmentyneit\u00e4 siit\u00e4, mit\u00e4 testata ilman koodia. Mutta se on tavanomainen asia ja kokemuksen my\u00f6t\u00e4 siit\u00e4 tulee sujuvaa. Ensimm\u00e4inen testi kirjoitetaan kirjoittamatta koodia ja ilmoittaa luokka ja menetelm\u00e4, ja testiss\u00e4 on kokoamisvirhe. Seuraava askel olisi korjata kokoamisvirhe ja suorittaa testi ep\u00e4onnistuaksesi. T\u00e4m\u00e4 aiheuttaa punaisen lipun.<\/p>\n\n

Vihre\u00e4 vaihe<\/strong><\/h3>\n\n

Punaisen vaiheen j\u00e4lkeen seuraava vaihe olisi koodin kirjoittaminen. T\u00e4m\u00e4n koodin on l\u00e4p\u00e4ist\u00e4v\u00e4 ensimm\u00e4inen testi. Pelkk\u00e4 koodin kirjoittaminen sen varmistamiseksi, ett\u00e4 vain ensimm\u00e4inen testi l\u00e4p\u00e4isee, on este, jonka monet kehitt\u00e4j\u00e4t kohtaavat aluksi. Koska seuraavassa testiss\u00e4 sen pit\u00e4isi ep\u00e4onnistua ja sen j\u00e4lkeen uusi koodi niiden l\u00e4p\u00e4isemiseksi. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

Refraktorin vaihe<\/strong><\/h3>\n\n

Kahdessa ensimm\u00e4isess\u00e4 vaiheessa, joissa testin on ensin ep\u00e4onnistuttava ja sitten l\u00e4p\u00e4ist\u00e4v\u00e4, tavoitteena oli saada testit l\u00e4p\u00e4ist\u00e4viksi. Mutta Refractor -vaiheessa on otettava huomioon muita tekij\u00f6it\u00e4, kuten koodin laatu, koodin yll\u00e4pidett\u00e4vyys, koodin luettavuus jne. T\u00e4ss\u00e4 keskityt\u00e4\u00e4n siis n\u00e4ihin n\u00e4k\u00f6kohtiin, joten yksikk\u00f6testit keskittyv\u00e4t niihin. Refactoring -vaiheessa sinun ei tarvitse huolehtia puuttuvasta toiminnallisuudesta, koska kun koodimuutokset tapahtuvat, testitapaukset vastaavat automaattisesti my\u00f6s toiminnallisuusosaa.<\/p>\n\n

TDD sopii hyvin ketter\u00e4\u00e4n menetelm\u00e4\u00e4n<\/strong><\/h3>\n\n

On aivan selv\u00e4\u00e4, ett\u00e4 projektivaatimukset voivat muuttua pitk\u00e4lle kehitysvaiheeseen, joten TDD: n saaminen yhteisty\u00f6ss\u00e4 ketter\u00e4n kehityksen kanssa tekee siit\u00e4 varmasti menestyv\u00e4n ja rakentaa projekteja asiakkaiden vaatimusten mukaisesti. Testipohjaisen kehityksen avulla saat aikaisemman palautteen projektista, jonka kanssa voit helposti ty\u00f6skennell\u00e4. <\/p>\n\n

Se auttaisi my\u00f6s ennakoimaan ja v\u00e4hent\u00e4m\u00e4\u00e4n kriittisi\u00e4 pullonkauloja ja varmistaa, ett\u00e4 projekti etenee suunnitellusti. Kehitt\u00e4j\u00e4tiimit voivat s\u00e4\u00e4st\u00e4\u00e4 paljon aikaa, koska testit luodaan paljon aikaisemmin projektin kehitysvaiheessa, eik\u00e4 heid\u00e4n tarvitse huolehtia laajoista testikomentosarjoista. <\/p>\n\n

Johtop\u00e4\u00e4t\u00f6s<\/strong><\/h3>\n\n

Testipohjainen kehitys on tekniikka, joka todellakin vie aikaa, mutta on arvokas siin\u00e4 mieless\u00e4, ett\u00e4 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\u00e4n aikaa ja rahaa. <\/p>\n\n

Mielenkiintoisia linkkej\u00e4:<\/p>\n\n

Testivetoinen kehitys: mik\u00e4 se on ja mik\u00e4 ei.<\/a><\/p>\n\n

Lis\u00e4tietoja testipohjaisesta kehityksest\u00e4<\/a><\/p>\n\n

Kuvat: Canva<\/p>\n\n

\"\"<\/figure><\/div>\n\n

Kirjoittaja: Sascha Thattil ty\u00f6skentelee Software-Developer-India.com -sivustolla, joka on osa YUHIRO-ryhm\u00e4\u00e4. YUHIRO on intialainen saksalainen yritys, joka tarjoaa ohjelmoijia IT-yrityksille, virastoille ja IT-osastoille.<\/p>\n