Yksikkötestauksen käyttöönotto

Esitys aiheesta: "Yksikkötestauksen käyttöönotto"— Esityksen transkriptio:

1 Yksikkötestauksen käyttöönotto
Jouni Heikniemi, Offbeat Solutions @jouniheikniemi

2 No heippa! Jouni Heikniemi yleisjyrä Offbeat Solutions
@jouniheikniemi

3 #td2012fi #tddev

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! 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 %
”Lisäsuunnittelu” Kehitys-työ Kehitys-työ Ilman yksikkötestejä Yksikkötestien kanssa

13 … “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

14 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

15 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

16 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

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

19 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

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

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ä koodin laadun melko hyvin Testit toimivat myös dokumentaationa Syntyy helposti ”huonoja testejä”: rikkoutuvat koodin rakenteen muuttuessa

43 Code Coverage

44 Code Coverage

45

46

47

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)

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

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

53 Miten varmistua testien laadusta?
Katselmointi. Erityisesti testien. Loistava tapa saada palautetta myös koodin ajattelusta ja API-suunnittelusta

54 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”

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

56

57 Kokeile rohkeasti. Kehityt koodaajana.

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