Mitu testi tuleb kirjutada?
20.04.2009 | Gunnar
Eeee…… 600 testi sellise vidina kohta vä? Kas te teate ka mis ajakulu see on või? Sellised küsimused küsiti kord mu käest. Tegemist oli klassikalise projektijuhiga, kes küll automaatsest testimisest ühte-teist kuulnud, kuid enda projektides neid veel katsetanud polnud. Kas oleksid need 600 testi ennast õigustanud või mitte? Ja üldse, kui palju teste tuleb kirjutada?
Sama hästi võiks küsida, et kui palju õlut tuleks juua, et korralikult purju jääda. On vastuseid, mis on enam-vähem alumise piiri peal, kuid alati leidub ka vastuseid, mis on ilmselge liialdus. Kaks kasti õlut õhtu kohta ühele inimesele oleks liialdus minu meelest, aga võin ka muidugi eksida. Liiga suure koguse korral saavutaksime küll eesmärgi, kuid saaksime boonusena kaasa päris palju sebimist raviasutustega. Umbes sama lugu on ka testidega - mõõdukas koguses täidavad nad eesmärki, kuid üle ei tasu pingutada.
Millal testimine tulemusi ei anna?
Leidub neid, kes eemalduvad testide kirjutamisest, sest ei näe mingeid tulemusi. Piisab sellest, kui kirjutada teste kas liiga vähe või testida lihtsalt valesti. Alguses juhtub mõlemat, selles võite päris kindlad olla. Samuti on oluline kirjutada teste sellises järjestuses, et korduvad probleemid tuleksid välja eos.
Juhul, kui on mängus andmebaas, kirjutan ma kohe algul valmis ka integratsioonitestid, sest elu on näidanud, et lihtsad muudatused andmebaasis, mida keegi teine kiiruga teeb, võivad integratsioonitestide tasemel süsteemis vigu tekitada. Loomulikult tahan ma need vead kohe tuvastada, enne kui kulutatakse aega süsteemi paigaldamisele keskkonda, kus tellija süsteemi kallal tegutseda saab.
Kui neid teste ei kirjutaks, siis võib lihtsasti juhtuda, et tuleb käsitsi ajada andmebaasi ja koodi mööda taga probleemseid kohti, kus vigu hakkab tekkima tänu sellele, et O/R-mapper ei tea, kuidas antud juhul objektide ahelaid andmebaasist kustutada.
Millal testimine aega hakkab raiskama?
Kui teste kirjutada liiga palju, siis kulub loomulikult rohkem aega ka nende testide sünkroniseerimisele koodis tehtavate muudatustega. Paar nö. liigset testi ei ole probleem, kuid näiteks 200 või 3000 liigset testi pakub juba päris tõsist tegevust, kui midagi muutub.
Mis kasu annab piisav testimine?
Piisav testimine võib päris palju aega kokku hoida just projekti teises pooles ja järeltoe ajal. Aga loomulikult ka projekti alguses. Testi kirjutamine on ühekordne investeering, mida saavad kasutada kõik arendajad, kes antud projektis koodiga tegelevad. Seega kui üks kirjutab testi, siis saavad oma muudatuste mõju testimiseks seda kasutada ka kõik teised.
Testimise teema juures jäävad projektijuhid enamasti urgitsema pisidetailide kallale nagu testide kirjutamiseks kuluv aeg. Muide, kui asi juba käpas on, siis need 600 testi kirjutab valmis üks inimene näiteks nädala või kahega – olenevalt sellest, milliseid teste ja kui palju täpselt vaja läheb.
Kui mitu päeva, nädalat või kuud hoiaks aga kokku see kui 99% tehnilist praaki tuleks välja arendajate endi silma all, mitte üllatusena testijatelt või kliendilt?
Mitu testi siis vaja on ikkagi?
Õige vastus: täpselt nii palju, et tehniline rämps ei jõuaks kaugemale masinast, kus jookseb kompilaator.
21.04.2009 kell 18:23
Testimine ei tohiks kunagi aega raisata. Kui koodi muutmisel tuleb pidevalt sünkroniseerida, siis võib tegemist olla õrnade testidega (Fragile Tests) ning see annab märku sellest, et testid on halavasti kirjutadud, üle spetsifitseeritud või disain on veidi lombakas.
Koodi kaetavus annab väikese ülevaate selle kohta, kas tuleks hakata teste juurde kirjutama või võib rahulduda praeguse seisuga. Hea oleks saada kaetavus üle 80%, kuid 100% jahtida pole väga mõistlik. Siinkohal tasuks meelse pidada, et 80% koodi kaetavus ei ütle, et midagi testide kvaliteedi ega ka testitud osade kohta. Seda tuleks käsitleda, et kui protsent liiga väike on, siis tuleb midagi ette võtta.
22.04.2009 kell 14:17
Üks päris hea nõks, mida pragmaatikud soovitavad, on see, et kui muidu mingil põhjusel teste ei saa kirjutada (”me ei hakka sellele aega raiskama” ja muud toredad ettepanekud “kõrgemalt”), siis alati võib kirjutada teste nende asjade kohta, mis vähemalt korra on katki läinud. See garanteerib, et kui keegi teine vea taastab, siis ei lipsa see läbi.
23.04.2009 kell 08:31
Üks võimalus on automaatseid teste võtta kui käivitatavat spetsifikatsiooni. Siis ei saa neid liiga palju, ega ka mitte liiga vähe
24.04.2009 kell 10:32
Alati on olemas võimalus, et need saavad liiga keerulised või mahukad. Proovitud ja nähtud - omal nahal.
24.04.2009 kell 18:38
Võib-olla võetakse liiga suured tükid ette. Testid räägivad nii mõndagi objektide disaini kohta.
28.04.2009 kell 12:02
Kui meetodid on pikad ja keerulised, siis on neid ka raske testida. Antud juhul aitab siis see, et lõhkuda suured meetodid pisemateks ja testida neid. Kuid… on ka juhtumeid, kus nii lihtsasti ei pääse, sest kood pole lihtsalt testitav.