Lataa esitys
Esittely latautuu. Ole hyvä ja odota
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
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
57
Kokeile rohkeasti. Kehityt koodaajana.
58
jouni@offbeat.fi @jouniheikniemi www.heikniemi.net/hardcoded
? @jouniheikniemi
Samankaltaiset esitykset
© 2024 SlidePlayer.fi Inc.
All rights reserved.