Tässä artikkelissa tarkastelen testivetoisen kehityksen tilastoja ja tutkimuksia ymmärtääkseni, miten sitä on hyödynnetty, mitä hyötyjä se tarjoaa ja millaisia haasteita tiimit kohtaavat tätä lähestymistapaa käyttäessään.
Perinteisesti ohjelmistokehitys etenee lineaarisesti. Viime vuosikymmeninä ketterien järjestelmien yleistyessä (jopa 87% tiimeistä noudattaa ketterää tai sen kaltaista lähestymistapaa) ohjelmistokehityksessä on kuitenkin alettu hyödyntää erilaisia menetelmiä, joissa otetaan huomioon projektin vaatimukset ja luonne.
Testivetoinen kehitys (TDD) on yksi menetelmistä, jotka ovat herättäneet huomiota ketterän ohjelmistokehityksen alueella.
Sähkö- ja elektroniikkainsinöörien instituutin julkaisemassa tutkimuksessa kirjoittajat Yahya Rafique ja Vojislav Misic toteavat, että ”testivetoinen kehitys (TDD) kuuluu ääriohjelmoinnin (XP) kehitysprosessin kulmakivikäytäntöihin” (Lähde).
TDD:n kehittäjänä pidetyn henkilön kerrotaan ”todenneen vuonna 2003, että TDD kannustaa yksinkertaisiin suunnitteluratkaisuihin ja herättää luottamusta” (Lähde). TDD:hen liittyvistä tuottavuutta ja laatua koskevista väitteistä esitetään kuitenkin edelleen kysymyksiä.
Käytimme aikaa uusimpien TDD-tilastojen keräämiseen testataksemme esitettyjä väitteitä.
Tässä artikkelissa määritellään ensin TDD:n käsite ja se, miten se eroaa perinteisestä lähestymistavasta. Sen jälkeen tarkastelemme tilastoja, jotka joko vahvistavat TDD:stä esitetyt väitteet tai kumoavat ne.
Mitä testivetoinen kehitys on?
Testivetoinen kehitys on lähestymistapa, jossa testi kirjoitetaan ennen kuin ohjelmistokehittäjä luo testin täyttävän tuotantokoodin. Tämän tekniikan perusajatuksena on antaa koodin kirjoittajalle aikaa pohtia suunnittelua tai vaatimuksia ennen toiminnallisen koodin kirjoittamista.
TDD-prosessi
- Testin kirjoittaminen: TDD:ssä kaikki uudet ominaisuudet alkavat testin kirjoittamisella. Ohjelmoijan on ymmärrettävä ominaisuuden määritykset ja vaatimukset. Tämän saavuttamiseksi hänen on käytävä läpi käyttäjätarinoita ja käyttötapauksia ymmärtääkseen kehitettävän uuden koodin tarkoituksen.
- Testi epäonnistuu: Kun ohjelmoija on kirjoittanut testin, hän suorittaa sen. Koska sen toteuttavaa koodia ei vielä ole, testi epäonnistuu. Tämä vahvistaa, että automaattinen testauskehys toimii oikein ja sulkee pois sen mahdollisuuden, että uusi testi läpäistäisiin aina sen virheellisyyden vuoksi.
- Koodin kirjoittaminen: Nyt ohjelmoija tietää, että ominaisuus toimii suunnittelun mukaisesti. Hän kirjoittaa koodin, joka läpäisee testin. Koodi ei ehkä ole täydellistä tai läpäise testiä erinomaisesti, mutta sillä ei ole merkitystä. Kehittäjän ei odoteta kirjoittavan koodia testin tarkistaman toiminnallisuuden ulkopuolelta.
- Testien suorittaminen: Kun ohjelmoija tietää, että ominaisuus toimii suunnitellusti, hän voi käyttää uutta koodia julkaistessaan testinhallintatyökalua testin suorittamiseen uudelleen. Näin hän saa vahvistuksen siitä, ettei uusin päivitys ole rikkonut aiempaa ominaisuutta.
- Koodin uudelleenjärjestely: TDD:ssä koodikantaa on siistittävä jatkuvasti sen kasvaessa. Koska ohjelmoijan pääpaino edellisissä vaiheissa oli pelkästään koodin kirjoittamisessa, tämä vaihe varmistaa tehokkuuden. Sen avulla ohjelman lähdekoodin sisäistä rakennetta voidaan parantaa samalla, kun sen ulkoiset ominaisuudet säilytetään. Tässä vaiheessa voidaan poistaa päällekkäisyyksiä ja lisätä uusia toimintoja.
- Toistaminen: Edellä kuvatut vaiheet toistuvat automaattisesti, jotta TDD-syklit kattavat kaikki ominaisuudet.
Have an account? Log In
TDD:n ja perinteisen kehityksen erot
TDD:n ymmärtämiseksi on tarkoituksenmukaista selvittää, miten se eroaa perinteisistä ohjelmointitavoista.
Keskeinen ero on se, että perinteiset menetelmät noudattavat lineaarista prosessia, kun taas TDD etenee syklisesti.
Perinteisiä testausmenetelmiä käyttävät ohjelmoijat aloittavat luomalla koodin ja keskittyvät testiin vasta kehitysprosessin lopussa. Toisaalta TDD-mallia noudattava henkilö aloittaa luomalla testin ja kehittää sitten testin täyttävän koodin. Tämä lähestymistapa jakaa monia periaatteita ohjelmistotestauksen shift left -liikkeen kanssa.
Perinteistä lähestymistapaa käyttävä ohjelmoija voi kiinnittää huomiota koodin oikeellisuuteen, mutta samalla hän saattaa jättää havaitsematta kaikki koodin virheet. TDD-menetelmää käyttävä ohjelmoija työstää koodia, kunnes se läpäisee testin, refaktoroimalla koodia. Tätä jatketaan, kunnes koodi täyttää toiminnalliset vaatimukset, minkä tuloksena on todennäköisesti vähemmän virheitä.
Onko TDD hitaampaa vai nopeampaa kuin perinteinen testikehitys?
Siitä, nopeuttaako TDD ohjelmointiprosessia, on saatavilla eri lähteistä ristiriitaisia tilastoja.
Microsoftin ja IBM:n ohjelmistoinsinööritiimejä koskeneessa tapaustutkimuksessa todettiin, että “tiimit kokivat alkuperäisen kehitysajan pidentyneen 15–35 prosenttia”, kun ne käyttivät TDD-tekniikkaa. Tutkimuksessa kuitenkin huomautetaan, että nämä luvut olivat “johdon subjektiivisesti arvioimia” (Lähde).
Kun asiaa tarkastellaan siitä näkökulmasta, että Microsoftin ja IBM:n tutkimukset osoittavat laadun parantuneen, voidaan väittää, että pitkällä aikavälillä TDD säästää aikaa, joka muuten olisi kulunut ongelmien korjaamiseen. Microsoftin ja IBM:n tiimit olivat samaa mieltä tästä näkemyksestä (Lähde).
Tutkimuksessa, jossa tarkasteltiin kokeneiden ammattilaisten ensivaikutelmia TDD:n käytöstä, todetaan, että “kun osallistujat ovat voittaneet alkuvaiheen vaikeudet ymmärtää, mistä aloittaa, ja oppineet luomaan testin ominaisuudelle, jota ei vielä ole olemassa, he saavat paremman varmuuden uusien ominaisuuksien toteuttamiseen ja muutosten tekemiseen laajan testikattavuuden ansiosta” (Lähde). Tämä näyttää viittaavan siihen, että asiat paranevat ajan myötä.
Verkkojulkaisualustalle Medium.com kirjoittava ohjelmoija ja “Composing Software” ja “Programming JavaScript Applications” -teoksen kirjoittaja Erick Elliot keskittyy siihen, miten TDD muutti hänen elämänsä. Elliot myöntää, että prosessi voi aluksi olla hidas, mutta sanoo: “jossain vaiheessa noin kahden vuoden kohdalla alkoi tapahtua jotain taianomaista: aloin kirjoittaa koodia yksikkötesteillä nopeammin kuin koskaan aiemmin ilman niitä” (Lähde).
Vaikuttaa siltä, että TDD:n käyttö saattaa aluksi hidastaa asioita. Pitkällä aikavälillä tarkasteltuna paremmanlaatuisen koodin ansiosta säästetty aika voi kuitenkin kompensoida alussa menetetyn ajan. Lisäksi voidaan olettaa, että ohjelmoijien kehittyessä TDD:n käytössä he todennäköisesti työskentelevät nopeammin.
Laadukkaan tuloksen saavuttamiseen kuluvan ajan mittaamisessa on otettava huomioon myös monia muita tekijöitä. Lisätietoa aiheesta saat kuuntelemalla Niall Lynchin jakson The QA Lead -podcastissa aiheesta T2Q:n (Time To Quality) mittaaminen.
Johtaako TDD vähäisempään virheiden määrään?
Edellä käydyssä keskustelussa yksi TDD:n tärkeimmistä esiin tuoduista eduista on se, että se johtaa vähäisempään virheiden määrään. Ovatko tilastot kuitenkin samaa mieltä?
Samat edellä mainitut Microsoftin ja IBM:n insinööritiimejä koskeneet tutkimukset päätyivät siihen, että “neljän tuotteen julkaisua edeltävä virhetiheys väheni 40–90 prosenttia verrattuna vastaaviin projekteihin, joissa TDD-käytäntöä ei käytetty”. IBM:n tiimit ilmoittivat virhetiheyden vähentyneen 40 prosenttia, kun taas Microsoftin tiimit ilmoittivat 60–90 prosentin vähennyksestä (Lähde).
Tukevatko testivetoisen kehityksen tilastot johtopäätöstä, että TDD tuottaa parempaa laatua?
Maria Siniaalto ja Pekka Abrahamsson raportoivat Suomessa vuonna 2007 järjestetyssä IEEE:n ensimmäisessä kansainvälisessä symposiumissa esitellyn tutkimuksen tulosten perusteella, että TDD:n on osoitettu tuottavan laadukkaampaa koodia kuin ilman TDD:tä kehitetyt ohjelmistot (Lähde).
Siniaalto ja Abrahamsson viittaavat artikkelissaan Kiinassa tehtyyn tutkimukseen, jossa todettiin, että TDD paransi prosessin seurantaa ja tehtävien arviointia. Samassa tutkimuksessa todetaan, että ”TDD edistää myös johdonmukaisten käytäntöjen ja ohjeiden noudattamista.” Tämä johtaa parempaan laatuun ja vähäisempään virheiden määrään. Lisäksi TDD:tä käyttäneet tiimit pystyivät korjaamaan virheensä nopeammin (Lähde).
Kehittäjien keskuudessa tehty tutkimus, jossa osallistujilla oli keskimäärin noin kymmenen vuoden työkokemus ja jossa selvitettiin heidän näkemyksiään TDD:tä käytettäessä, siteeraa kehittäjää, joka sanoo: ”TDD on auttanut minua parantamaan koodia ja tehnyt siitä luettavampaa.” Toinen osallistuja kertoo, että ”TDD mahdollistaa paremman ylläpidettävyyden” (Lähde).
Edistääkö TDD yksinkertaisempaa suunnittelua?
North Carolina State Universityn tietojenkäsittelytieteen laitoksella työskentelevät Boby George ja Laurie Williams toteuttivat kokeen, jossa 24 ohjelmoijaa jaettiin kahteen ryhmään: toinen käytti TDD:tä ja toinen lineaarista lähestymistapaa.
George ja Williams raportoivat, että osallistujista ”92 % kehittäjistä uskoi TDD:n tuottavan laadukkaampaa koodia, 79 % ajatteli TDD:n edistävän yksinkertaisempaa suunnittelua ja 71 % piti lähestymistapaa huomattavan tehokkaana” (Lähde).
Nämä testivetoisen kehityksen laatua koskevat tilastot antavat vahvan viitteen siitä, että TDD todellakin johtaa laadukkaampaan koodiin ja yksinkertaisempaan suunnitteluun.
Ilmaisessa oppimisportaalissa Guru99.com julkaistussa artikkelissa Kanchan Kulkarni sanoo: ”TDD tekee koodista yksinkertaisempaa ja selkeämpää. Sen ansiosta kehittäjä tarvitsee vähemmän dokumentaatiota” (Lähde).
Onko TDD-suunnittelun käyttöönotto helppoa?
Georgen ja Williamsin kokeessa 56 % ammattilaiskehittäjistä uskoi, että TDD-ajattelutapaan siirtyminen oli vaikeaa, kun taas 23 % katsoi vaikeuden johtuvan alustavan suunnitteluvaiheen puuttumisesta. Kaikista vastauksista 40 %:ssa uskottiin, että TDD:n käyttöönotto on vaikeaa (Lähde).
Nämä testivetoisen kehityksen käyttöönottoa koskevat tilastot osoittavat, että TDD:n käyttöönottoa pidetään vaikeana.
More Articles
Onko TDD yliarvostettua?
Medium.com-sivustolla julkaistussa artikkelissa Tylor Borgeson, joka kuvailee itseään koneoppimisesta, tekoälystä, infrastruktuurista, DevOpsista ja ketteristä menetelmistä kiinnostuneeksi täyden pinon ohjelmistokehittäjäksi, käyttää otsikkoa ”Testivetoinen kehitys on yliarvostettua.” Se, että hän on laittanut otsikon lainausmerkkeihin, osoittaa kuitenkin, ettei kyseessä ole hänen esittämänsä väite.
Borgeson käsittelee seuraavaksi niitä, joiden mielestä menetelmä on yliarvostettu ja hidas, ja kertoo heille, että useimmat tätä mieltä olevat eivät ole käyttäneet menetelmää riittävän pitkään. Artikkelinsa lopussa hän sanoo: ”Mene nyt harjoittelemaan testivetoista kehitystä, kunnes se ei enää tunnu pahalta” (Lähde).
Mitä seuraavaksi?
Opi laadunvarmistuksen lähestymistapoja asiantuntijoilta The QA Lead -podcastissa
Tilaa The QA Lead -uutiskirje, niin saat uusimmat ohjeemme ja podcast-jaksomme
Liity The QA Lead -verkkoyhteisöfoorumin jonotuslistalle, jossa voit jakaa parhaita käytäntöjä muiden laadunvarmistuksen ja ohjelmistotestauksen ammattilaisten kanssa.
Toivottavasti tapaamme siellä!
