Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

Miksi kirjoittaa yksikkötestejä?

Olen kirjoittanut yksikkötestejä n. 7 vuotta. Vasta viime aikoina olen oppinut uusia tapoja yksikkötestien kirjoittamiseen. Mutta miksi ihmeessä yksikkötestejä kirjoitetaan?

Miksi

  1. Luotettavuus. Yksikkötesti on ainoa tapa varmistaa, että koodi tekee nyt ja tulevaisuudessa haluamani asiat. Jos minä tai joku muu muokkaa koodia, niin yksikkötestillä voi varmistaa, ettei vanha toiminnallisuus mene rikki.
  2. Yksikkötestillä testaaminen käy nopeammin, jos testiä varten pitää sovellus saada tiettyyn tilaan. Testaajan sisäänkirjautuminen ja erilaisten testitapausten luominen vie hyvän tovin.
  3. Parempilaatuinen koodi. Yksikkötestattava koodi on yksinkertaista. Yksikkötestejä kirjoittaessa jättimetodit ja monimutkaiset kokonaisuudet pikkoutuvat pienempiin osiin kuin itsestään. Muut kehittäjät lukevat tällaista koodia meilummin kuin 2000 rivin hirviömetodia, jossa on runsaasti if-lohkoja.
     
    Lisäksi muilta kuultua:

  4. Vähentää koodista löytyviä virheitä (bugit).
  5. Voi tehdä suuria muutoksia koodiin nopeasti.
  6. Välitön palaute koodatessa. Tiedät heti koodisi toimivan, kun syttyy vihreä valo.
  7. Testien avulla näkee miten metodin on tarkoitus toimia.
  8. Testien avulla ymmärtää koodin rakenteen paremmin.
  9. Yksikkötestin avulla pääsee helposti liikkeelle koodaamisessa, jos pitää luoda suurempi kokonaisuus.
  10. Testien kirjoittaminen on hauskaa.

Se maksaa

Pieniä erilaisia asioitaNiin maksaa. Yksikkötestien kirjoittaminen vie hieman enemmän aikaa, mutta menetetty aika ja raha saadaan takaisin virheiden vähentyessä (luotettavuus), tuoteen laadun parantuessa (asiakastyytyväisyys), ylläpiettävyydessä (koodia voi muokata ja refaktoroida tai optimoida nopeammaksi) ja virheiden metsästyksen helpottuessa.

Yksikkötestattu koodi sisältää vielä virheitä. Kehittäjä joskus ymmärtää väärin ja kirjoittaa siksi viallista koodia tai unohtaa jonkin erikoistapauksen. Tällöin kirjataan vika. Kirjoitetaan yksikkötesti, jolla todetaan virheen toistuvan. Korjataan koodi. Vanhoista yksikkötesteistä näkee heti, ettei aiempi toiminnallisuus hajonnut. Käsin testattaessa prosessi olisi hitaampi, koska uudelleentestaus kestää.

Mitä ei kannata testata

Käyttöliittymän ulkoasun tai toimintojen yksikkötestaaminen on harvoin kannattavaa. Elementtien sijainti ja ulkoasu korjataan tyypillisesti kerran.

Jos sovellus käyttää omaa tietokantaa, datan oikeellisuutta ei tarvitse testata. Tallennan kantaan aina hyvälaatuista dataa. Mikäli data tulee ulkoisesta järjestelmästä, jonkun rajapinnan kautta, niin testaaminen voi olla perusteltua.

Tiedon oikeellisuus testataan korkeintaan kerran. Tyypillinen tilanne on testata käyttäjän antama syöte esimerkiksi sotu. Kun sosiaaliturvatunnus todetaan olevan oikeassa muodossa, sitä ei tarvitse myöhemmin tarkistaa. Vapaan tekstikentän sisällön tarkistaminen on järjetöntä. Käyttöliittymäkomponenteille voi antaa kentän maksimipituuden, jolloin vältytään turhilta tekstin pituustarkastuksilta.

Kaikkia tapauksia EI testata. Yksikkötesteihin kirjoitetaan joitain mahdollisia virhetapauksia, joilla voidaan varmiistaa metodin hyvä käytös virheellisellä syötteellä esim. null. Jos koodi laskee jotain, riittää todeta induktiivisesti, että se toimii. Siis tapauksessa 0, perusarvot. Tapauksessa yksi ja n+1. Yksikkötestin sisällä ei pitäisi koskaan olla for-silmukkaa.

Mitä seuraavaksi

Ota kehitysympäristö esille ja aloita yksikkötestien kirjoittaminen!

Katso myös

Mainokset

Single Post Navigation

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggers like this: