Yksikktestauksen kyttnotto Jouni Heikniemi Offbeat Solutions jouniheikniemi jounioffbeat

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

#td 2012 fi #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 t täällä! . . . No m ihän ole utta siks

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 voi n i k ä iest sim E : a t Muis ! aa vaiht ol. fi m www. ww r. fi nste w. mo . fi tyo tie t. oiko a k i a p jne. inos) en ma (ilmain

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” Kehitystyö Ilman yksikkötestejä Kehitystyö Yksikkötestien kanssa

Paljonko se vie aikaa? Virhejahti Testien toteutus … “mutta” Lisäsuunnittelu Kehitystyö Ylläpitokoodaus Kehitystyö Testien ylläpito Virhejahti Ylläpitokoodaus Ilman yksikkötestejä Yksikkötestien kanssa

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

Paljonko se vie aikaa? Virhejahti Testien toteutus Lisäsuunnittelu Kehitystyö Testinkirjoitustaidot ratkaisevat, Ylläpitoväheneekö virhejahti. koodaus Testien ylläpito Kehitystyö Virhejahti Ylläpitokoodaus Ilman yksikkötestejä Yksikkötestien kanssa

Paljonko se vie aikaa? Virhejahti Testien toteutus Lisäsuunnittelu Kehitystyö Huonot testit ovat myös tuskaisia Ylläpitoylläpitää. koodaus Testien ylläpito Kehitystyö Virhejahti Ylläpitokoodaus Ilman yksikkötestejä Yksikkötestien kanssa

Vaikuttaako lohduttomalta? Virhejahti Testien toteutus LisäJopa 80 % sovelluksen suunnittelu TCO: sta kohdistuu ylläpitoon. Kehitystyö Ylläpitokoodaus Testien ylläpito Kehitystyö Virhejahti Ylläpitokoodaus Ilman yksikkötestejä Yksikkötestien kanssa

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

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

Testauksen aloittamisen työmäärä Idean tajuaminen Työkalut kuntoon Testien kirjoittaminen Siis: Kaikki oikeasti vaikea duuni on omien jälkien siivoamista. Riippuvuuksien poistaminen

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? — Legacyssa löytyy (tm) — Oma tupa, oma lupa — Sekasorron voi kääntää myös voitoksi — ”Kukaan ei huomaa” — Ehkä parempaa koodia — Uusissa alustoissa parempi testaustuki — Hermoraunio projektipäällikkö niskassa?

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

Riippuvuuksien vaikeus Tehokkuus koodiluokittain Data access (yleensä) Ohjauskerrokset Fasadikerrokset Parserit ym. muuntimet Työkalumetodit ”Ä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ä?

Riippuvuuksien vaikeus Mitä kannattaisi testata? Data access (yleensä) Ohjauskerrokset Fasadikerrokset Parserit ym. muuntimet Työkalumetodit ”Älyttömät” oliot Laskenta ja päättely Testauskelpoisen logiikan määrä

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

Riippuvuuksien vaikeus Helpot vaikeat ensin? Data access (yleensä) Ohjauskerrokset Fasadikerrokset Parserit ym. muuntimet Työkalumetodit ”Älyttömät” oliot Laskenta ja päättely Testauskelpoisen logiikan määrä

Helpot 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 1. Kirjoita testi aina ennen kuin refaktoroit – Varmista että testi testaa oikeat asiat – ja menee läpi sekä ennen että jälkeen 2. 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

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 • 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ä! – n. Unit, x. Unit, Mbunit, Mstest, . . . – Moq, Typemock Isolator, Rhino. Mocks, . . . Hyvä setti aloittelijalle: – Visual Studio, Re. Sharper, Team. City, TFS, . . . x. Unit + (Test. Driven. net tai Re. Sharper) • Oikeasti valinnalla ei ole yhtään mitään väliä kun olet aloittamassa

Tarvittavaa osaamista • • • Vähän testauksen filosofiaa Jokin testaustyökalu Refaktorointi Oman softan toimintasäännöt Mock-tekniikat, Io. C, 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/katselmointi 1 http: //bit. ly/katselmointi 2

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 checkin pala ute Testien pitää suorittua nopeasti kehittäjän työasemalla Build + test Versionhallinta

Kokeile rohkeasti. Kehityt koodaajana.

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