Embed Size (px)
DESCRIPTION
Yksikkötestauksen käyttöönotto. Jouni Heikniemi, Offbeat Solutions. @ jouniheikniemi [email protected]. No heippa!. Jouni Heikniemi yleisjyrä Offbeat Solutions [email protected] www.heikniemi.net/hardcoded @jouniheikniemi. #tddev. #td2012fi. Odotukset kuulijalle. - PowerPoint PPT Presentation
Citation preview
#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?
Softamme on liian monimutkainen
Minulla ei ole aikaa
Yritin, mutta en osannut
Esimieheni ei anna lupaa
(... jolloin testit ovat osa ratkaisua, eivät ongelmaa)
... No mutta siksihän olet täällä!
Miksi edes kysyt?
Esimieheni ei anna lupaa
Esimieheni ei anna lupaa
KulttuuriTulospaineKvartaali
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...
• Laadukasta koodia kustannustehokkuutta
• Dokumentaatiota• Luottamusta koodin
oikeellisuuteen
• Bugittomuutta• Testaajien
tarpeettomuutta
saa ei saa
(= toimii kuten toteuttaja on aikonut)
Yksikkötestaus ”Koodinvarmistus”
Paljonko se vie aikaa?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
”Lisäsuunnittelu”
+ 20 .. 100 %
Paljonko se vie aikaa?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
Lisä-suunnittelu
Ylläpito-koodaus
Ylläpito-koodaus
Virhe-jahti
Virhejahti
Testienylläpito
… “mutta”
Paljonko se vie aikaa?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
Lisä-suunnittelu
Ylläpito-koodaus
Ylläpito-koodaus
Virhe-jahti
Virhejahti
Testienylläpito
Tiimin refaktorointitaidot
ratkaisevat, väheneekö ylläpitovaiva.
Paljonko se vie aikaa?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
Lisä-suunnittelu
Ylläpito-koodaus
Ylläpito-koodaus
Virhe-jahti
Virhejahti
Testienylläpito
Testinkirjoitustaidot ratkaisevat,
väheneekö virhejahti.
Paljonko se vie aikaa?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
Lisä-suunnittelu
Ylläpito-koodaus
Ylläpito-koodaus
Virhe-jahti
Virhejahti
Testienylläpito
Huonot testit ovat myös tuskaisia
ylläpitää.
Vaikuttaako lohduttomalta?
Kehitys-työ
Ilman yksikkötestejä Yksikkötestien kanssa
Kehitys-työ
Testientoteutus
Lisä-suunnittelu
Ylläpito-koodaus
Ylläpito-koodaus
Virhe-jahti
Virhejahti
Testienylläpito
Jopa 80 % sovelluksen TCO:sta kohdistuu ylläpitoon.
Elinkaari huomioidenKe
hity
styö
Ilman yksikkötestejä Yksikkötestien kanssaKe
hity
styö
Testi
ento
teut
us
Lisä-
suun
nitte
lu
Ylläpitokoodaus
Ylläpito-koodaus
Virhejahti
Virhejahti
Testien ylläpito
Tiimin kehityksen myötäKe
hity
styö
Ilman yksikkötestejä Yksikkötestien kanssaKe
hity
styö
Testi
ento
teut
us
Lisä
-su
unni
ttelu
Ylläpitokoodaus
Ylläpito-koodaus
Virhejahti
Virhejahti
Testien ylläpito
Testauksen aloittamisen työmäärä
Idean tajuaminen
Työkalut kuntoon
Testien kirjoittaminen
Riippuvuuksien poistaminen
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äänottaa täysillä turpaan...
• Keskikokoinen projekti tai moduuli
• Tunnetusti ongelmallinen
• Jonka tunnet melko hyvin
Ideaalinen Frankenstein
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!
Tehokkuus koodiluokittainRi
ippu
vuuk
sien
vaik
eus
Testauskelpoisen logiikan määrä
Data access(yleensä)
”Älyttömät” oliot
Työkalu-metodit
Parserit ym. muuntimet
Laskenta ja päättely
Fasadi-kerrokset
Ohjaus-kerrokset
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?Ri
ippu
vuuk
sien
vaik
eus
Testauskelpoisen logiikan määrä
Data access(yleensä)
”Älyttömät” oliot
Työkalu-metodit
Parserit ym. muuntimet
Laskenta ja päättely
Fasadi-kerrokset
Ohjaus-kerrokset
Helpot testit
Vaikeat testit
Yksikkötestien työmäärävaikutukset
Kehitys-työ
Ylläpito-koodaus
Virhejahti
Testienylläpito
Testientoteutus
Lisä-suunnittelu
Miksi testata vaikeita asioita?
Helpot vai vaikeat ensin?Ri
ippu
vuuk
sien
vaik
eus
Testauskelpoisen logiikan määrä
Data access(yleensä)
”Älyttömät” oliot
Työkalu-metodit
Parserit ym. muuntimet
Laskenta ja päättely
Fasadi-kerrokset
Ohjaus-kerrokset
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
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
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ä koodinlaadun 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/katselmointi1http://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
Testien pitää suorittua nopeastikehittäjän työasemalla
Version-hallintacheckin
Build + test
palaute
Kokeile rohkeasti.Kehityt koodaajana.
