Sissejuhatus automaattestimisse
10.05.2010 | GunnarTestimise kohalt nõustub pea iga arendaja sellega, et testid on vajalikud. Paljud nõustuvad ka sellega, et testid aitavad ära hoida hulga igasugust jama. Kuid neid, kes teste ka tegelikkuses kirjutavad, on küllaltki vähe – hoolimata teadmisest, et jah, nii on hea ja parem. Käesolevas kandes annan mõned juhised neile, kes soovivad oma tarkvara hakata automaatsete testidega toetama ja saavutada seeläbi oma töö senisest kõrgem kvaliteet.
Milleks koodi testida?
Testidega kood teeb tarkvarafirma elu olulisel määral lihtsamaks. Millised on peamised võidud?
- korduv tehniline praak tuleb välja kiiresti ja tänu testidele saavad programmeerijad selle tagasiside kätte minutite või sekunditega, mitte inimtestijate kaudu päevade jooksul,
- testidega kaetud koodi on palju ohutum muuta, sest tagasisidet muudatuste kohta saame testidelt – kui midagi läks katki, siis testid ütlevad seda,
- olulisel määral vähenevad ka vead sellest koodist, mis jõuab tellijateni, sest inimtestijad ei testi enamasti üle kõiki koodiradu, mis süsteemis esinevad (tihti nad ei tunne süsteemi tehnilist ehitust nii palju, dokumentatsioonid ei pruugi katta kõiki detaile jne).
Lühidalt – testide abil tõuseb koodi kvaliteet oluliselt ja seeläbi langeb ka aeg, mis kulub tehnilise praagiga tegelemisele.
Müüdid
Nagu iga uue asjaga ikka, siis loovad inimesed sadu tonte enne kui maha rahunevad ja mõtlema hakkavad. Nii on ka automaattestidega juhtunud. Egas muud kui vaatame peamised väärarusaamad üle, millele ma kohe vastu ka vaidlen.
- Automaattestid on professionaalide mängumaa. Ei ole nii, sest testimist võib õppida ka iga algaja. Saadaval on palju häid raamatuid, samuti leiab palju materjali kui seda internetist iseseisvalt otsida. Alati võib abi küsida foorumitest, kus spetsialistid lahkesti algajaid abistavad.
- Testide kirjutamine võtab väga palju aega. Kui elu esimese kahe-kolme testi põhjal otsustada, siis on see tõesti nii. Kui võtta päeva-paari harjutamise järel uuesti hinnata, siis pole ajakulu enam teab kui suur. Peale paari nädalat läheb kõik juba väga kiiresti.
- Testide kirjutamisest saadav kasu pole märgatav. Kui pole märgatav, siis on arvatavasti testid kas valesti kirjutatud, neid on liiga vähe või ei kata nad süsteemi võimalikke probleemseid kohti. Alati on olemas ka variant, et ärikoolist tulnud mänekas pole enda jaoks veel kalkulaatori ja Exceli võlusid avastanud või ei tule selle peale, et ajakulust tuleb maha lahutada mõne analoogse projekti korduvatele vigade silumisele kulunud aeg. Kui palju võtab aega task üksi või task koos testidega, pole adekvaatne võrdlusmaterjal.
- Me ei saa teste mahutada niigi tihedatesse projektigraafikutesse. No shit, Sherlock, sul on lugu suht halb siis ja vajab parandamist. Arvatavasti on need graafikud just seepärast tihedad, et kasutajate käes olevatest projektidest tuleb igapäev lisategemisi juurde uute vigade näol. Alusta testimisega ja mõne aja pärast on see ajakulu suuresti kadunud.
- Testid eeldavad kallite töövahendite ostmist. Kui null krooni on kallis, siis on see tõesti nii. On olemas nii odavaid, kalleid kui ka täiesti tasuta vahendeid, mida kasutada.
Töövahendid
Mina kasutan käesolevas näites Visual Studio 2010 Ultimate poolt pakutavaid vahendeid. Kellel on versioon, kus testimise vahendeid pole, siis saab kasutada kolmandamate parteide poolt pakutavat toodangut:
Alustamiseks peaks need mõlemad piisavad olema ja kes kasutavad Express-versioone ei pea ka muret tundma – mõlemad vahendid peaks võimaldama ka testide jooksutamist käsurealt.
Testimisvahendeid on saada ka teiste platvormide jaoks. Siin siis mõningane valik:
Meil populaarsemad platvormid on vast sellega nüüd kaetud. Rubyl tunduvad testide jaoks vajalikud vahendid kohe kaasas olevat. Äkki jõuab ka Visual Studio enne mu surma sinnani, et kvaliteetse tarkvara kirjutamine on vaikimisi eelistatud.
Peamised muudatused testideta koodis
Peamised muudatused, mis testideta koodis tuleb teha, on kõik seotud sellega, et testideta kood ei ole enamasti testitav. Või kui natukene on, siis on seda päris raske testida. Vähemasti ilma keerukaid ja kahtlaseid häkke täis testideta. Peamised muudatused, mis koodis juhtuvad, on järgmised:
- staatilises skoobis toimuvat jääb oluliselt vähemaks,
- senised suured klasside pusad muutuvad pisemaks ning süsteemi tehniline arhitektuur ja disain muutuvad oluliselt paremaks,
- kindlasti tuleb kasutusele võtta uusi vahendeid, mida eelnevalt vaja ei läinud (näiteks IoC konteiner),
- meetodid muutuvad oluliselt lühemaks, sest spageti pikkuseid meetode on raske testida (ära muretse, spagett pole niigi hea disainitava).
Esimesed kogemused
Minu esimesed kogemused testideta koodiga olid päris piinarikkad, sest igasugused liiga targad staatilised klassid ja meetodid sättisid ennast koos oma vajadustega jalgu. Kuna nende funktsionaalsusega kaasneb kõik, mis nad reaalses keskkonnas teevad, siis on nende tegevuse kontrollimine päris keerukas.
Üldiselt hakkab kõik tasapisi ilmet võtma. Esimese barjäärina tuleb üle saada testide kirjutamise loogikast, sealt edasi läheb juba päris libedalt kui süsteem ise õudusunenägu pole. Vaikselt kasvab ka testide kirjutamise kiirus ja peatselt muutub prioriteetseks mõtlemises see, et kuidas koodi kirjutada selle arvestusega, et see oleks testitav.
Ühesõnaga, midagi hullu pole. Algus on ehk natuke raske, kuid need raskused elab kiiresti ja suht valutult üle. Edasi läheb ainult kergemaks.