Skrevet av Anders tor, 17/02/2011 - 11:16
I forbindelse med et kort oppdrag for RBK har vi satt opp automatiske tester av en webapplikasjon ved hjelp av Selenium. Kort fortalt er Selenium et verktøy som går inn i applikasjonen og simulerer brukeratferd. De som har brukt JUnit-testing tidligere vil umiddelbart kjenne seg igjen, men den store forskjellen er at JUnit tester kode mens Selenium tester grensesnitt.
Selenium IDE
Selenium IDE er en plugin til Firefox, der brukerens adferd blir registrert. Dette “opptaket” kan så brukes til å generere kjørbar kode i de fleste programmeringsspråk. Koden kan så lagres og kjøres på nytt igjen fra Selenium IDE. På den måten får man regresjonstestet webapplikasjonen på en svært enkel måte. Selenium IDE er imidlertid begrenset til bare Firefox.
Selenium IDE kan også brukes til å sjekke at en side har bestemte elementer. Hvis du feks ønsker å sjekke at et bilde faktisk har blitt lastet, kan du høyreklikke på dette og velge bildet fra en nedtrekksmeny. I koden blir det da lagret en sjekk på at bildet er lastet og koden vil kaste en exception dersom bildet ikke finnes.
Under vises et eksempel på kode som ble generert da jeg logget inn. I tillegg har jeg lagt inn verify-statements for å sjekke at enkelte elementer finnes.
Selenium RC (Remote Control)
Hvis man ønsker å teste en webapplikasjon i flere browsere så kommer Selenium IDE til kort. Løsningen er å sette opp Selenium RC-server som kjører testkoden for deg. Dette er en stand-alone javaserver som kan fjernstyres enten fra din egen testapplikasjon eller fra enkelte programmer. Eclipse støtter dette direkte. Serveren sørger da for å åpne alle angitte browsere og teste koden i disse. Hvis ingenting annet angis lages da et konsollvindu som viser resultatene av testkjøringen. Denne kan konfigureres til å skrives til andre steder, feks en loggfil som lagres på serveren.
Selenium Grid
Testing av webapplikasjoner forutsetter at alt som skal testes faktisk blir åpnet og kjørt som om det var en bruker som gjorde det. Sider skal lastes og dette kan ta tid, særlig om man ønsker å teste i større skala, cross-browser og i flere operativsystemer. Hvis man ønsker å kjøre alle testene hver gang applikasjonen bygges så er sjansen stor for at dette vil ta uakseptabelt lang tid.
Selenium Grid løser dette ved å kjøre testene i parallell. Testene kan da være skrevet i andre programmeringsspråk enn java og kjøres i heterogene miljøer. Alle logger vil da også bli lagret på samme sted og man kan umiddelbart se hvilke tester som eventuelt feiler.
Vedlikehold
Det anses som en god praksis å skrive tester først og kode etterpå. På den måten sikrer man seg at koden gjør det man faktisk hadde tenkt i spesifikasjonen. Hvis man har lagd JUnit-tester så har man også erfart at endringer ofte medfører at testene feiler og må skrives om for å reflektere den nye koden. På samme måte vil også tester som kjøres i Selenium feile hvis det lages endringer i grensesnittet. Automatisk testing med Selenium anbefales derfor først og fremst gjort i forbindelse med akseptansetesting.
