Veebirakenduste automaatne testimine – capybara-webkit vs poltergeist

Veebirakenduste automaatseks testimiseks on mitmeid võimalusi, üks neist on testida rakendust läbi kasutajaliidese – kasutades selleks siis kas päris- või headless-brauserit.

Kasutajaliidese kaudu testimisega kaasneb paratamatult hulk probleeme, alates sellest, et testid on suhteliselt aeglased võrreldes rakenduse backend‘i service‘i tasemel testimisega. Jah, palju asju saab veebirakenduste puhul testida kasutajaliidest absoluutselt puudutamata, kuid on ka olukordi, kus tuleb seda teha.

Näiteks on kasutajaliidese kaudu testimine praktiliselt ainus võimalus testida rakendust tegeliku kasutaja vaatepunktist, samuti võimaldab see teostada end-to-end testimist ning mis kõige tähtsam – veenduda, kas meie veebirakenduse frontend üldse töötab.

Lisaks eelmainitud potentsiaalsele aeglusele on kasutajaliidese testid juba oma loomult suhteliselt ebastabiilsed – näiteks võib muutuda kasutajaliides, samuti ei ole veebirakenduse renderdamine alati ühtlaselt kiire, sõltudes muuhulgas näiteks võrguühendusest. See kõik mõjutab teste. Enamuse sellist laadi probleemide jaoks on loomulikult olemas lahendused ja hästi kirjutatud testide puhul ei ole – üldjuhul – need tõsiseks komistuskiviks. Küll aga võivad osutuda probleemseks kohaks valitud tööriistad, sealhulgas veebirakenduste testimise üks kriitilisemaid komponente, milleks on brauser ning selle draiver.

Olles kirjutanud automaatseid veebiteste juba rohkem kui aasta Ruby’s, olen kasutanud lisaks erinevatele raamistikele järgmisi brauseri draivereid: selenium-webdriver, capybara-webkit ning poltergeist. Esimene neist töötab päris-brauseriga – vaikimisi on selleks Firefox -, viimased aga jooksutavad headless-brausereid ning edasises keskenduksin just neile.

Suuremahulise testide kogumiku puhul on oluline, et testid jookseksid stabiilselt ja usaldusväärselt, et nende ülesseadmine ning käivitamine oleks võimalikult lihtne ning testid võiksid loomulikult olla ka kiired. Kiirust mõjutab suuresti platvorm, millel teste jooksutada – nii on Windows Ruby koodi jooksutamiseks tunduvalt aeglasem keskkond, kui Linux või OS X. Testide stabiilsust mõjutab palju headless-brauseri ja selle draiveri valik – kui palju see kasutab testikeskkonnas ressursse, kui hästi ja kiiresti see meie veebirakendust renderdab ning kuidas on lood jõudlusega renderdatud veebilehe DOM‘is navigeerimisel.

Capybara-webkit

Capybara-webkit on headless-brauseri draiver, mis jooksutab WebKit‘i põhist brauserit. Capybara-webkit sõltub Qt teekidest, mille WebKit‘i implementatsiooni ta kasutab, ning vajab jooksmiseks ka graafilist süsteemi (näiteks X.org). Koos kõigi sõltuvustega on tegu päris raskekaaluline tööriistaga, mis reaalses kasutuses on aga suhteliselt stabiilne.

Sõltuvus graafilisest keskkonnast toob aga kaasa ka ühe olulisema murekoha – kuna brauser renderdatakse graafiliselt virtuaalses framebuffer‘is, on mälukasutus testide jooksmise ajal suhteliselt kõrge. Lisaks, kui mingil põhjusel peaks mõni test hanguma või ootamatult surema, jääb capybara-webkit‘i protsess tihti käima ning kui selle eemaldamine ununeb, tekivad järgmisel testide käivitamisel probleemid.

Poltergeist

Just põhjusel, et capybara-webkit sõltub liiga paljudest välistest teekidest ning ka suhteliselt kõrge ressursinõudluse tõttu otsustasin katsetada alternatiivseid vahendeid. Valituks osutus PhantomJS – samuti WebKit‘i põhine headless-brauser, mis aga ei sõltu pea ühestki välisest vahendist. Nii on Windows’i ja OS X’i jaoks loodud eelkompileeritud pakid täiesti iseseisvad, vaid Linuxi versioonid vajavad lisaks mõningaid teeke fontide renderdamiseks. Pole vaja ka graafikasüsteemi. PhantomJS‘i draiver minu kasutatud veebitestimise raamistiku (capybara) jaoks ongi poltergeist.

Millised olid siis muljed? Tegu on 100% drop-in asendusega draiveri kasutamise seisukohalt, ka ei vaja testid olulisi muudatusi koodis, seega puhtalt tehnilisest küljest hindeks väga hea. Küll aga jäid alles probleemid, mis olid tingitud veebirakenduse laadimise kiirusest. Siin aga on abiks poltergeist‘i tunduvalt paremad veateated – tagasisidet antakse, kui veebileht oodatud aja jooksul ei ole laetud, kui otsitud element on mõne teise elemendi taga ja ei ole käideldav, isegi Javascripti vigadest teavitatakse.

Testikeskkonna ülesseadmise seisukohalt on PhantomJS ja poltergeist tunduvalt sõbralikumad – kui capybara-webkit vaja Qt teeke (ning sõltuvalt capybara-webkit‘i versioonist võib vaja minna vägagi konkreetset Qt versiooni) ning graafikasüsteemi, siis PhantomJS on iseseisev ja ei oma väliseid sõltuvusi.

Lisaks annab poltergeist testide arendaja käsutusse ühe väga olulise võimaluse, millest capybara-webkit‘i kasutamisel tihti puudust tundsin – omamoodi analoogi päris-brauseritest tuttavalt debugger‘ile. Kasutades meetodit page.driver.network_traffic, on võimalik kuvada lehekülje laadimisel tehtud võrgupäringuid ning nende vastuseid.

Mis siis poltergeist‘i (ja PhantomJS‘i) nii heaks teeb?

  • Deterministlikum, kui capybara-webkit – probleemid, kui neid on, ilmnevad üldjuhul alati samas kohas ja samamoodi; testid ei ebaõnnestu nii juhuslikult
  • Vähem sõltuvusi, lihtsam paigaldada
  • Nõuab vähem ressursse testikeskkonnalt
  • Informatiivsemad veateated ja paremad võimalused debug‘imiseks
  • Tuvastab ka lehel esinevad Javascripti vead, isegi kui test muidu oleks edukas

Lõpetuseks tekib kindlasti küsimus, kas ma siis ise kasutan nüüd oma testides PhantomJS’i ja poltergeist’i? Oodatud vastus oleks ilmselt “jah”, tegelik vastus on hetkel veel aga “veel mitte”. Seda seetõttu, et antud rakendusele kirjutatud testide hulk on väga suur – üle 1000 – ning uuele tehnilisele lahendusele üleminek vajab põhjalikku testimist ning olemasolevate testide täielikus toimimajäämises veendumist, mis on mõnevõrra aeganõudev protsess.

Kas ma aga kavatsen oma testid lõpuks poltergeist‘ile üle viia? Jah, kindlasti.

Lisaks plaanin edaspidi tuua välja ka võrdluse mõlema draiveri jõudlusest ning anda lühikese ülevaate suure hulga kasutajaliidese testide regulaarse jooksutamise stabiilsusest pikemas plaanis.

Leave a Reply

Your email address will not be published. Required fields are marked *