Yksikkötestauksen käyttöönotto Jouni Heikniemi, Offbeat Solutions @jouniheikniemi jouni@offbeat.fi

No heippa! Jouni Heikniemi yleisjyrä Offbeat Solutions jouni@offbeat.fi www.heikniemi.net/hardcoded @jouniheikniemi

#td2012fi #tddev

Odotukset kuulijalle Tietää mitä yksikkötestaus on Osaa kirjoittaa perustestin Kehittäjä tai muuten prosessissa tiukasti kiinni Ei vielä aktiivinen yksikkötestaaja

Miksi et yksikkötestaa? Esimieheni ei anna lupaa Minulla ei ole aikaa Softamme on liian monimutkainen (... jolloin testit ovat osa ratkaisua, eivät ongelmaa) Yritin, mutta en osannut ... No mutta siksihän olet täällä!

Esimieheni ei anna lupaa Miksi edes kysyt?

Esimieheni ei anna lupaa Kulttuuri Tulospaine Kvartaali ROI

Esimieheni ei anna lupaa Täysverinen yksikkötestauksen käyttöönotto on organisaatiokysymys. Se, että sinä opettelet testaamaan töitä tehdessäsi, ei ole. Kun olet ensin opetellut, olet paljon vakuuttavampi.

Esimieheni ei anna lupaa Muista: Esimiestäkin voi vaihtaa! www.mol.fi www.monster.fi tyopaikat.oikotie.fi jne. (ilmainen mainos)

Enemmän realismia, vähemmän höpinää tai sitten presentoija kuuseen?

Mitä yksikkötestauksella... saa ei saa Laadukasta koodia  kustannustehokkuutta Dokumentaatiota Luottamusta koodin oikeellisuuteen Bugittomuutta Testaajien tarpeettomuutta (= toimii kuten toteuttaja on aikonut) Yksikkötestaus  ”Koodinvarmistus”

Paljonko se vie aikaa? Testien toteutus + 20 .. 100 % ”Lisäsuunnittelu” Kehitys-työ Kehitys-työ Ilman yksikkötestejä Yksikkötestien kanssa

… “mutta” Paljonko se vie aikaa? Virhe-jahti Testien toteutus Lisä-suunnittelu Ylläpito-koodaus Kehitys-työ Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Tiimin refaktorointitaidot ratkaisevat, väheneekö ylläpitovaiva. Paljonko se vie aikaa? Tiimin refaktorointitaidot ratkaisevat, väheneekö ylläpitovaiva. Virhe-jahti Testien toteutus Lisä-suunnittelu Ylläpito-koodaus Kehitys-työ Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Testinkirjoitustaidot ratkaisevat, väheneekö virhejahti. Paljonko se vie aikaa? Virhe-jahti Testien toteutus Lisä-suunnittelu Testinkirjoitustaidot ratkaisevat, väheneekö virhejahti. Ylläpito-koodaus Kehitys-työ Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Huonot testit ovat myös tuskaisia ylläpitää. Paljonko se vie aikaa? Virhe-jahti Testien toteutus Lisä-suunnittelu Ylläpito-koodaus Huonot testit ovat myös tuskaisia ylläpitää. Kehitys-työ Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Vaikuttaako lohduttomalta? Virhe-jahti Testien toteutus Jopa 80 % sovelluksen TCO:sta kohdistuu ylläpitoon. Lisä-suunnittelu Ylläpito-koodaus Kehitys-työ Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Elinkaari huomioiden Virhejahti Ylläpitokoodaus Ilman yksikkötestejä Testien toteutus suunnittelu Lisä- Ylläpitokoodaus Kehitystyö Kehitystyö Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Tiimin kehityksen myötä Virhejahti Testien toteutus Ylläpitokoodaus suunnittelu Lisä- Kehitystyö Kehitystyö Testien ylläpito Virhejahti Ylläpito-koodaus Ilman yksikkötestejä Yksikkötestien kanssa

Testauksen aloittamisen työmäärä Siis: Kaikki oikeasti vaikea duuni on omien jälkien siivoamista.

Siis mitkä riippuvuudet?

Logiikkaan sekaantujat, the usual suspects Tiedostojärjestelmä Verkon käyttö Tietokanta Ajoympäristön käsittely

No mitä sit ku? (eli kuinka voitat sen monimutkaisen softan)

Aloita järkevästä vastuksesta

Menestys liian helpossa projektissa johtaa harhaan! (eikä välttämättä edes vakuuta ketään)

Turha myöskään ottaa täysillä turpaan...

Ideaalinen Frankenstein Keskikokoinen projekti tai moduuli Tunnetusti ongelmallinen Jonka tunnet melko hyvin

Uusi on aina uusi? Ehkä parempaa koodia Legacyssa löytyy (tm) Uusissa alustoissa parempi testaustuki Hermoraunio projektipäällikkö niskassa? Legacyssa löytyy (tm) Oma tupa, oma lupa Sekasorron voi kääntää myös voitoksi ”Kukaan ei huomaa”

Mitä kannattaa testata? Kilauta kehittäjälle!

Tehokkuus koodiluokittain Data access (yleensä) Ohjaus-kerrokset Fasadi-kerrokset Riippuvuuksien vaikeus Parserit ym. muuntimet Työkalu-metodit ”Älyttömät” oliot Laskenta ja päättely Testauskelpoisen logiikan määrä

Testaushyöty Logiikan määrä Testaushyöty = Riippuvuuksien määrä Huomioi myös: Koodin bugialttius ja bugien kriittisyys Kuinka usein koodi muuttuu? Kuinka paljon dokumentaatiosta on hyötyä?

Mitä kannattaisi testata? Data access (yleensä) Ohjaus-kerrokset Fasadi-kerrokset Riippuvuuksien vaikeus Parserit ym. muuntimet Työkalu-metodit ”Älyttömät” oliot Laskenta ja päättely Testauskelpoisen logiikan määrä

Miksi testata vaikeita asioita? Testien toteutus Helpot testit Lisä-suunnittelu Vaikeat testit Kehitys-työ Testien ylläpito Virhejahti Ylläpito-koodaus Yksikkötestien työmäärävaikutukset

Helpot vai vaikeat ensin? Data access (yleensä) Ohjaus-kerrokset Fasadi-kerrokset Riippuvuuksien vaikeus Parserit ym. muuntimet Työkalu-metodit ”Älyttömät” oliot Laskenta ja päättely Testauskelpoisen logiikan määrä

Helpot vai vaikeat ensin? Jos haluat hyödyn irti nopeasti, aloita vaikeista ... Mutta sitten pitää oikeasti osata Jos sinä tai tiimisi olette aloittelijoita, lähtekää helposta päästä liikkeelle ... Mutta varaudu olemaan kärsivällinen – osa hyödyistä tulee vasta paljon myöhemmin

”Testaa kun korjaat”-malli Kirjoita testi aina ennen kuin refaktoroit Varmista että testi testaa oikeat asiat – ja menee läpi sekä ennen että jälkeen Kirjoita testi aina ennen kuin korjaat bugin Varmista että testi ei mene läpi ennen korjausta, ja menee sen jälkeen Hyvä, mutta vaikea tehdä organisoidusti aloittelevalla porukalla

Black vs. White box

Elämää mustassa laatikossa Valmis?

Elämää valkeassa laatikossa

Elämää valkeassa laatikossa

Black vs. White box Testit ovat toteutusriippumattomia Lähes aina jotain jää testaamatta Lähes aina on myös turhia testejä ... ja käytännössä mahdotonta tehdä, ellei testejä tee joku muu kuin koodari  unohda tämä

Black vs. White box Testit varmentavat yleensä koodin laadun melko hyvin Testit toimivat myös dokumentaationa Syntyy helposti ”huonoja testejä”: rikkoutuvat koodin rakenteen muuttuessa

Code Coverage

Code Coverage

Code coverage Hyvä apuväline, kun etsit paikkoja, joita testikoodi ei ainakaan testaa Älä käytä peittoprosenttia mittarina tai tavoitteena ”Execution coverage” != ”Assertion coverage”

Mitä voisin mitata? Riippuvuuksien määrän vähenemistä Esim. NDepend-metriikat Regressiobugien määrää Hyvä, mutta usein hidas mittari Uusien koodarien työhönoppimisen nopeus Virheiden korjausnopeus Debuggaukseen käytetty aika

Työkaluja Apua mikä määrä! nUnit, xUnit, Mbunit, Mstest, ... Moq, Typemock Isolator, RhinoMocks, ... Visual Studio, ReSharper, TeamCity, TFS, ... Oikeasti valinnalla ei ole yhtään mitään väliä kun olet aloittamassa Hyvä setti aloittelijalle: xUnit + (TestDriven.net tai ReSharper)

Tarvittavaa osaamista Vähän testauksen filosofiaa Jokin testaustyökalu Refaktorointi Oman softan toimintasäännöt Mock-tekniikat, IoC, testien skriptaus, ...

Test-driven development Ei ole pakko. Sehän on tiiliseinä ---> Harkitse sitten, kun testaus alkaa sujua hyvin.

Miten varmistua testien laadusta? Katselmointi. Erityisesti testien. Loistava tapa saada palautetta myös koodin ajattelusta ja API-suunnittelusta http://bit.ly/katselmointi1 http://bit.ly/katselmointi2

Integraatio- vs. Yksikkötestit? Onko erottelu sinulle oikeasti merkityksellinen? Yksikkötesti = ”testaa vain yhtä luokkaa” ... vai ... Yksikkötesti = ”riittävän nopea ja simppeli, vapaasti toistettavissa oleva testi”

Testien ajoympäristöt Version-hallinta checkin palaute Testien pitää suorittua nopeasti kehittäjän työasemalla Build + test

Kokeile rohkeasti. Kehityt koodaajana.

jouni@offbeat.fi @jouniheikniemi www.heikniemi.net/hardcoded ? jouni@offbeat.fi @jouniheikniemi www.heikniemi.net/hardcoded