mikä on Test-Driven Development (TDD)?

large__8282043567Koelähtöinen kehitys on prosessi, joka nojaa hyvin lyhyen kehityskaaren toistoon. Se perustuu Test-first-konseptiin Extreme Programming (XP), joka kannustaa yksinkertaiseen suunnitteluun suurella luottamuksella.

TDD: n tekemismenettely on seuraava:

  1. kirjoita testi
  2. Suorita kaikki testit
  3. Kirjoita toteutuskoodi
  4. Suorita kaikki testit
  5. Refaktori

tätä menettelyä kutsutaan usein punavihreä-Refaktoriksi.

kokeita kirjoittaessamme olemme punaisessa tilassa. Koska testi kirjoitetaan ennen varsinaista toteutusta, sen oletetaan epäonnistuvan. Jos ei, testi on väärä. Se kuvaa jotain, mikä on jo olemassa tai se on kirjoitettu väärin. Vihreänä oleminen kokeita kirjoittaessa on merkki väärästä positiivisuudesta. Tuollaiset testit pitäisi poistaa tai muuttaa.

seuraavaksi tulee vihreä valtio. Kun viimeisen testin toteutus on valmis,kaikkien testien pitäisi läpäistä. Jos näin ei ole, toteutus on väärin ja se pitäisi korjata.

ideana ei ole tehdä toteutuksesta lopullista, vaan antaa juuri sen verran koodia, että testit läpäisevät. Kun kaikki on vihreää, voimme muokata olemassa olevan koodin uudelleen. Tämä tarkoittaa sitä, että teemme koodista optimaalisemman ilman uusia ominaisuuksia. Vaikka refaktorointi on käytössä, kaikkien testien pitäisi kulkea koko ajan. Jos yksi niistä epäonnistuu, refactor rikkoi olemassa olevan toiminnon. Refactoring ei saisi sisältää uusia testejä.

nopeus ratkaisee

large_5836417589
minulla on tapana nähdä TDD kuin peli ping pong (tai Pöytätennis). Peli on erittäin nopea. Sama pätee TDD: hen. En yleensä vietä enempää kuin minuutin molemmin puolin pöytää (testi ja toteutus). Kirjoita lyhyt testi ja suorita se (ping), Kirjoita toteutus ja suorita kaikki testit (pong), kirjoita toinen testi (ping), Kirjoita kyseisen testin toteutus (pong), refactor ja vahvista, että kaikki testit läpäisevät (pisteet), toista. Ping, pong, ping, pong, ping, pong, maali, syötä uudelleen. Älä yritä tehdä täydellinen koodi. Yritä sen sijaan pitää pallo pyörimässä, kunnes olet sitä mieltä, että aika on oikea pisteet (refactor).

kyse ei ole testauksesta

T TDD: ssä ymmärretään usein väärin. TDD on tapa, jolla lähestymme suunnittelua. Se pakottaa meidät miettimään toteutusta ennen koodin kirjoittamista. Se on tapa jäsentää koodia paremmin. Tämä ei tarkoita, että TDD: n käytöstä johtuvat testit olisivat hyödyttömiä. Kaukana siitä. Ne ovat erittäin hyödyllisiä ja antavat meille mahdollisuuden kehittyä nopeasti pelkäämättä, että jotain rikkoutuu. Tämä pätee erityisesti silloin, kun refaktorointia tapahtuu. Kyky järjestää koodi uudelleen, kun taas luottamus siihen, että mitään toiminnallisuutta ei ole rikki, on valtava piristysruiske koodin laadulle.

TDD: n päätavoitteena on koodin suunnittelu, jossa testit ovat erittäin hyödyllinen sivutuote.

pilkkaaminen

jotta testit sujuisivat nopeasti ja antaisivat jatkuvaa palautetta, koodi on järjestettävä siten, että menetelmiä, toimintoja ja luokkia voidaan helposti pilkata ja stubbata. Nopeus suoritus vaikuttaa vakavasti se, esimerkiksi meidän testit täytyy kommunikoida tietokantaan. Pilkkaamalla ulkoisia riippuvuuksia voimme lisätä tuota nopeutta rajusti. Koko yksikkötestisarjan suoritus on mitattava minuuteissa, ellei sekunneissa. Nopeutta tärkeämpää on, että koodin suunnittelu siten, että sitä voidaan helposti pilkata ja stubbata, pakottaa meidät jäsentämään koodin paremmin soveltamalla eriyttämistä huolista. Piloilla tai ilman, koodi pitäisi kirjoittaa niin, että voimme esimerkiksi helposti vaihtaa yhden tietokannan toiseen. Että ”toinen” voi olla esimerkiksi pilkattu tai muistitietokanta.

esimerkki Scalan pilkkaamisesta löytyy Scala Test-Driven Development (TDD): Unit Testing File Operations with Specs2 and Mockito article-ohjelmasta. Jos valitsemasi ohjelmointikieli ei ole Scala, artikkeli voi silti olla erittäin hyödyllinen, jotta näet kuvion, jota voidaan soveltaa mihin tahansa kieleen.

valvojat

erittäin hyödyllinen työkalu TDD-muotiin työskenneltäessä ovat valvojat. Ne ovat kehyksiä tai työkaluja, jotka suoritetaan ennen kuin alamme työskennellä ja tarkkailevat muutoksia koodin. Kun tällainen muutos havaitaan, kaikki testit suoritetaan. JavaScriptin tapauksessa lähes kaikki build systems ja task runners sallivat tämän. Gulp (suosikkini) ja Grunt ovat kaksi monista esimerkeistä. Scalassa on SBT-revolveri (mm. Useimmilla muilla ohjelmointikielillä on samanlaiset työkalut, jotka kääntävät (tarvittaessa) ja suorittavat kaikki (tai vaikuttavat) testit koodin muuttuessa. Päädyn aina siihen, että näyttöni jaetaan kahteen ikkunaan. Toinen koodilla, jota työstän, ja toinen testituloksilla, joita tehdään jatkuvasti. Minun tarvitsee vain kiinnittää huomiota siihen, että noiden tarkkailijoiden ulostulo vastaa sitä vaihetta, jossa olen (punainen tai vihreä).

dokumentaatio

toinen TDD: n (ja yleisesti hyvin jäsenneltyjen testien) erittäin hyödyllinen sivuvaikutus on dokumentointi. Useimmissa tapauksissa on paljon helpompaa selvittää, mitä koodi tekee tarkastelemalla testejä kuin itse toteutus. Lisäetu, jota muunlaiset asiakirjat eivät voi tarjota, on se, että testit eivät ole koskaan vanhentuneita. Jos testien ja toteutuskoodin välillä on eroja, testit epäonnistuvat. Epäonnistuneet testit tarkoittavat virheellistä dokumentaatiota.

testit dokumentaationa-artikkeli tarjoaa hieman syvällisemmän perustelun testien käytölle perinteisen dokumentaation sijaan.

Yhteenveto

kokemukseni mukaan TDD on luultavasti tärkein työkalu, joka meillä on ohjelmistotyökalupakissamme. Se vie paljon aikaa ja kärsivällisyyttä tulla taitava TDD, mutta kun taide on hallittu, tuottavuus ja laatu kasvaa rajusti. Paras tapa sekä oppia että harjoitella TDD: tä on pariohjelmointi. Kuten pingispelissä, joka vaatii kaksi osallistujaa, TDD voi olla pareittain, jossa toinen koodari kirjoittaa testejä ja toinen kirjoittaa näiden testien toteutuksen. Roolit voivat vaihtua jokaisen testin jälkeen (kuten dojos-koodauksessa usein tehdään).

kokeile, äläkä luovuta, kun eteen tulee esteitä, sillä niitä tulee paljon.

Test Driven Development (TDD): parhaat käytännöt Java-esimerkkien avulla on hyvä lähtökohta. Vaikka se käyttää Java esimerkkejä, samoja, ellei kaikkia, käytäntöjä voidaan soveltaa mihin tahansa ohjelmointikieleen. Esimerkiksi Java (kuten edellisessä tapauksessa, se on helposti sovellettavissa muihin kieliin) tutustu TDD esimerkki läpivalaisu artikkeli.

toinen hyvä tapa täydellisyyteen TDD-taidot ovat koodikatas (niitä on paljon tällä sivustolla).

mitä kokemuksia sinulla on TDD: stä? Variaatioita on yhtä paljon kuin sitä harjoittelevia joukkueita, ja haluaisin kuulla kokemuksestasi.

Vastaa

Sähköpostiosoitettasi ei julkaista.