Tarinat vs. yksikkötestit
antti.a...@gmail.com
Pohdin tässä yo. kysymystä ja mietin mitä huonoja puolia tarinoilla
on? Hitaus? Kuinka hitaaksi tarinoiden ajo muodostuu isoissa
projekteissa?
Eli tarvitaanko yksikkötestejä ollenkaan ja jos niin miksi?
Olen todennäköisesti pohtinut tätä liian kauan, enkä näe enää metsää
puilta :)
-antti
Jarkko Laine
On 28.5.2008, at 10.35, an...@kiskolabs.com wrote:
>
> Moi!
>
> Pohdin tässä yo. kysymystä ja mietin mitä huonoja puolia tarinoilla
> on? Hitaus? Kuinka hitaaksi tarinoiden ajo muodostuu isoissa
> projekteissa?
>
> Eli tarvitaanko yksikkötestejä ollenkaan ja jos niin miksi?
Kyllä.
Tarinoiden idea on käydä läpi todennäköisimmät käyttötapaukset ja
toimia koko pinon integraatiotesteinä. Kuten mainitsit, ne ovat
hitaita ja siksi kaikkien permutaatioiden käyminen läpi niiden avulla
ei ole järkevää. Sen sijaan ne muodostavat loistavan lähtökohdan
porautua syvemmälle sovellukseen yksikkötestien avulla.
Yksikkötesteissä testattavana olevaa yksikköä (kontrolleri, malli,
näkymä) testataan eristyksissä muusta maailmasta, minkä takia ne ovat
erittäin nopeita, ja itse asim. pidän autotestiä jatkuvasti käynnissä
ajamassa speksejä aina, kun jokin muuttuu koodissa. Tarinoiden kanssa
tämä olisi käytännössä mahdotonta.
//jarkko
>
>
>
> Olen todennäköisesti pohtinut tätä liian kauan, enkä näe enää metsää
> puilta :)
>
> -antti
> --~--~---------~--~----~------------~-------~--~----~
> Saat tämän viestin, koska olet tilannut ryhmän Google-ryhmät "Ruby
> on Rails: Finnish" ryhmä.
> Lähettääksesi viestejä tähän ryhmään käytä sähköpostiosoitetta finnis...@googlegroups.com
> Kun haluat lopettaa ryhmän tilauksen, lähetä sähköpostia
> osoitteeseen finnishrails...@googlegroups.com
> Lisää toimintoja saadaksesi vieraile ryhmän sivustolla http://groups.google.com/group/finnishrails?hl=fi
> -~----------~----~----~----~------~----~------~--~---
>
--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi
antti.a...@gmail.com
> On 28.5.2008, at 10.35, an...@kiskolabs.com wrote:
> > Eli tarvitaanko yksikkötestejä ollenkaan ja jos niin miksi?
>
> Kyllä.
>
> Tarinoiden idea on käydä läpi todennäköisimmät käyttötapaukset ja
> toimia koko pinon integraatiotesteinä. Kuten mainitsit, ne ovat
> hitaita ja siksi kaikkien permutaatioiden käyminen läpi niiden avulla
> ei ole järkevää. Sen sijaan ne muodostavat loistavan lähtökohdan
> porautua syvemmälle sovellukseen yksikkötestien avulla.
> Yksikkötesteissä testattavana olevaa yksikköä (kontrolleri, malli,
> näkymä) testataan eristyksissä muusta maailmasta, minkä takia ne ovat
> erittäin nopeita, ja itse asim. pidän autotestiä jatkuvasti käynnissä
> ajamassa speksejä aina, kun jokin muuttuu koodissa. Tarinoiden kanssa
> tämä olisi käytännössä mahdotonta.
taakse on mahdollista rakentaa tarpeeksi kattavat testit. Ongelmana
siis on tuo nopeus. Harmi. Tarinat kun ovat erittäin mielekäs tapa
kirjoittaa testejä.
Kiitoksia vastauksesta! Palaan työpöydän ääreen kirjoittamaan
speksejä! ;)
-antti
Jarkko Laine
> Näin arvelinkin jonkun vastaavan. Olen sitä mieltä, että tarinoiden
> taakse on mahdollista rakentaa tarpeeksi kattavat testit. Ongelmana
> siis on tuo nopeus. Harmi. Tarinat kun ovat erittäin mielekäs tapa
> kirjoittaa testejä.
Olen eri mieltä sikäli, että yksikkötestejä tarvitaan tästä
huolimatta, eikä syy ole pelkästään nopeudessa. Yksikkötestien/
speksien merkitys on myös siinä, että voit luottaa jonkin luokan
toiminnalisuuteen, irrallisena yksikkönä. Ja jos koodaat käyttäen
BDD:tä tai TDD:tä, ne ovat osa koko suunnittelu-/toteutusprosessia,
jossa koko sovelluksen toteutus ja osien rajapinnat muovautuvat. Itse
huomaan usein, että kontrollerispekseistä tulee mielestäni liian
monimutkaisia. Tämä on vahva merkki siitä, että yritän tehdä liikaa
asioita kontrollereissa. Tällöin refaktoroin koodia enemmän model-
puolelle, jolloin kontrollerispekseistä (ja itse kontrollereista)
tulee huomattavasti yksinkertaisempia. Model-spekseistä tulee tosin
pidempiä, mutta ainakin vastuutaso on tällöin oikea ja mallit on usein
helpompi eriyttää omia speksejään varten, jolloin kokonaisuus on
lyhyempi ja siistimpi.
Lisäksi muistuttaisin, että tarinoiden yksi tärkeimmistä
tarkoituksista on toimia rajapintana/kommunikaatiovälineenä asiakkaan
kanssa. Jos yrittää tehdä niistä kaikki permutaatiot ja kombinaatiot
kattavan paketin, asiakas on hyvin nopeasti pyörryksissä, ja sivuuttaa
tarinat koska ei jaksa lukea niitä läpi.
//jarkko
Edvard Majakari
> siinä, että voit luottaa jonkin luokan toiminnalisuuteen, irrallisena yksikkönä.
Samaa mieltä Jarkon kanssa. Jos esimerkiksi sovelluksessa on
käyttäjiä, joilla on noin kymmenen erilaista roolia ja
kukin rooli vaikuttaa esimerkiksi siitä mitä asioita voi tehdä, ei ole
mieltä rakentaa kymmeniä, lähes samanlaisia integrointitestejä
joiden ainoa ero on siinä, että luodulla käyttäjällä on joka kerta eri
rooli, ja toisinaan se voi tehdä joukon operaatioita ja toisinaan ei.
Sama koskee erityistilanteita kuten levytilan loppuminen,
verkkoyhteyden katkeaminen jne. joissa mock-olioiden avulla voidaan
helposti laatia
sopivat olosuhteet testattavalle yksikölle.
Testien tulee olla myös luettavia, ja luettavuus kärsii jos oikeasti
testattava asia esiintyy kahdella rivillä 120:stä rivistä
ohjelmakoodia, kuten integrointitesteissä helposti käy
--
"One day, when he was naughty, Mr Bunnsy looked over the hedge into
Farmer Fred's field and it was full of fresh green lettuces. Mr
Bunnsy, however, was not full of lettuces. This did not seem fair."
-- Terry Pratchett, Mr. Bunnsy Has An Adventure
antti.a...@gmail.com
> Samaa mieltä Jarkon kanssa. Jos esimerkiksi sovelluksessa on
> käyttäjiä, joilla on noin kymmenen erilaista roolia ja
> kukin rooli vaikuttaa esimerkiksi siitä mitä asioita voi tehdä, ei ole
> mieltä rakentaa kymmeniä, lähes samanlaisia integrointitestejä
> joiden ainoa ero on siinä, että luodulla käyttäjällä on joka kerta eri
> rooli, ja toisinaan se voi tehdä joukon operaatioita ja toisinaan ei.
> Sama koskee erityistilanteita kuten levytilan loppuminen,
> verkkoyhteyden katkeaminen jne. joissa mock-olioiden avulla voidaan
> helposti laatia
> sopivat olosuhteet testattavalle yksikölle.
pieni, jotta olisin päässyt näihin ongelmiin asti. Hyviä pointteja
molemmilla!
Tarinoiden luettavuudesta (asiakkaat) - tarinathan voitaisiin jakaa
asiakkaan kanssa läpikäytäviin ja "sisäisiin" laajempiin tarinoihin.
Mutta tälle ei tosiaan ole tarvetta jos kattavuus haetaan muilla kuin
tarinoilla.
-antti