Yksikkötestauksen käyttöönotto

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

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

3. #tddev #td2012fi

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

5. 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ä!

6. Esimieheni ei anna lupaa Miksi edes kysyt?

7. Esimieheni ei anna lupaa Kulttuuri Tulospaine Kvartaali ROI

8. 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.

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

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

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

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

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

14. 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

15. 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

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

17. 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

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

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

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

21. Siis mitkä riippuvuudet?

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

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

24. Aloita järkevästä vastuksesta

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

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

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

28. Uusi on aina uusi? • Ehkä parempaa koodia • 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”

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

30. 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ä

31. 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ä?

32. 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ä

33. 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

34. 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ä

35. 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

36. ”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

37. Black vs. White box

38. Elämää mustassa laatikossa Valmis?

39. Elämää valkeassa laatikossa

40. Elämää valkeassa laatikossa

41. 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ä

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

43. Code Coverage

44. Code Coverage

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

49. 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

50. 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)