Share
La oss bygge et system for å utføre funksjonstester på webapplikasjoner, ved hjelp av Selenium og PhantomJS. Det resulterende systemet vil tillate oss å skrive enkle testscenarier i JavaScript, og teste disse scenariene både i ekte nettlesere og en headless simulator.
Den åpenbare ulempen med Selen er at det krever et fullt grafisk skrivebord for alle tester.
For å begynne, må vi velge en nettleserkontroll eller emuleringsmotor for å simulere en sluttbruker. I lang tid var den primære aktøren i dette feltet Selen, og det er fortsatt. Selen gjør det mulig å automatisere kontrollen med ekte nettlesere på ekte operativsystemer, noe som er den viktigste fordelen: du kan være helt sikker på at testene representerer virkeligheten så tett som mulig.
Den åpenbare ulempen med Selen er at det krever et fullt grafisk skrivebord for alle tester. Som et resultat kan testene dine bli treg. Selen kan imidlertid være fantastisk, hvis du har de nødvendige ressursene for å sette opp virtuelle maskiner for forskjellige operativsystemer og koble sammen alt sammen.
På motsatt side av spekteret er PhantomJS: Et lite, men utmerket prosjekt, som kjører en WebKit-motor med full JavaScript-tilgang, men uten den grafiske delen. PhantomJS er en cinch å sette opp, kjører på hvilken som helst maskin, og er betydelig raskere.
Selen kan nå kontrollere PhantomJS på samme måte som det gjør en annen nettleser.
PhantomJS, som er en fullstendig WebKit, dekker 90% av dine funksjonelle testbehov. Tross alt, hvis søknaden din kjører i WebKit på riktig måte, er det sannsynligvis at det kjører riktig i andre nettlesere. Dette utelukker selvsagt Internet Explorer 6-8.
Men da prosjektet ditt blir stadig mer populært, blir de resterende 10% et betydelig problem. Hvis din funksjonelle testing suite er satt opp på PhantomJS direkte, ville det være vondt å omskrive testene for selen.
Heldigvis, nylig, nær haleenden av 2012, mottok vi en gave i form av PhantomJS-bindinger til Selen. Med andre ord kan Selen nå kontrollere PhantomJS på samme måte som det gjør en annen nettleser.
Gitt at Selen, i seg selv, ikke trenger noe komplisert oppsett og kan løpe hvor som helst, kan vi bruke Selenbinding til å kontrollere PhantomJS og dekke 90% av testbehovene våre. Hvis du senere trenger mer kraftig testing, kan du sette opp ekstra nettleserforbindelser til Selen uten å endre en enkelt linje i koden.
Dermed er vårt valg for nettlesermotoren Selen med PhantomJS.
Selen tilbyr bindinger i de fleste populære programmeringsspråk, så vi kan velge et språk i henhold til våre behov. Dette er kanskje den mest kontroversielle delen av denne artikkelen: Jeg anser JavaScript for å være det beste valget for å beskrive funksjonelle tester for nettsteder og webapplikasjoner.
Selenbindinger for JavaScript kalles, webdriverjs. Selv om prosjektet er mindre modent enn offisielt støttede drivere for Java, C #, Ruby og Python, inneholder det likevel allerede det meste av funksjonaliteten som vi krever.
I denne artikkelen har Mocha med Chai blitt valgt.
Til slutt trenger vi en testløper, eller et program for å kjøre tester etter navn, og utskrift av utskrift, mens du ser hvor mange tester som er lyktes eller feilet. Denne testløperen bør også tilby et påstandsbibliotek, som gjør det mulig for koderen å uttrykke om en test lykkes eller feiler.
Valget er helt gratis her. Det er mange JavaScript-testløpere, men i denne artikkelen har Mocha med Chai blitt valgt. Mokka gir en betydelig fleksibilitet, et bredt utvalg av utdataformater og den populære jasminlignende syntaksen. Chai lar deg skrive beskrivende BDD-lignende påstander.
Her er den endelige stabelen som vi skal bruke:
Fordi det meste av stabelen vår er basert på JavaScript, trenger vi node.js og npm. Begge disse er felles verktøy i samfunnet, og jeg antar at du allerede har satt dem opp. Hvis du ikke gjør det, må du bruke installasjonsprogrammet på node.js nettside. Ikke bekymre deg; Hvis noe går galt, er det nok av Node installeringsguider tilgjengelig rundt på nettet.
Alle tre av disse kan installeres, ved hjelp av NPM:
sudo npm installere -g mocha chai webdriverjs
Alternativt kan du installere dem lokalt i katalogen hvor testene dine er plassert:
npm installere mocha chai webdriverjs
Last ned Selenium Server. Det er distribuert som en enkelt krukke fil, som du bare kjører:
java -jar selen-server-standalone-2.28.0.jar
Så snart du utfører denne kommandoen, starter den opp en server som testkoden din vil koble til senere. Vær oppmerksom på at du må kjøre Selenium Server hver gang du driver testene dine.
Bruk NPM å installere PhantomJS globalt:
sudo npm installere -g phantomjs
Vi krever en ny versjon av PhantomJS - minst 1,8. Dette betyr at pakker levert av pakkebehandleren din (apt-get, MacPorts, ...) vil mest sannsynlig være utdatert.
Du kan installere ved hjelp av npm uten en global installasjon, eller bruke andre metoder manuelt. I dette tilfellet må du imidlertid fortelle Selen hvor du plasserte PhantomJS hver gang du kjører Selen:
PATH = "/ path / to / node_modules / phantomjs / bin: $ PATH" java -jar selen-server-standalone-2.28.0.jar
Nå som vi har alle delene, må vi sette alt sammen.
Husk: Før du kjører noen tester, må du kjøre Selenium Server:
java -jar selen-server-standalone-2.28.0.jar
Selen vil drive PhantomJS internt; du trenger ikke å bekymre deg for det.
Nå må vi koble til Selen fra JavaScript. Her er en prøvebit, som starter en forbindelse til Selen og har et klart objekt for å kontrollere vår Selen-forekomst:
Accentsconagua
// Bruk webdriverjs for å opprette en Selenclient var client = require ('webdriverjs'). Fjernkontroll (desiredCapabilities: // Du kan velge andre nettlesere // http://code.google.com/p/selenium/wiki/ DesiredCapabilities browserName: 'phantomjs', // webdriverjs har mye utgang som er generelt ubrukelig // Men hvis noe går galt, fjern dette for å se flere detaljer logLevel: 'silent'); client.init (); Nå kan vi beskrive våre tester og bruke klient variabel for å kontrollere nettleseren. En fullstendig referanse for webdriverjs-API er tilgjengelig i dokumentasjonen, men her er et kort eksempel:
client.url ('http://example.com/') client.getTitle (funksjon (tittel) console.log ('Tittel er', tittel);); client.setValue ('# field', 'value'); client.submitForm (); client.end (); La oss bruke Mokka og Chai syntaks for å beskrive en test; vi skal teste noen egenskaper av example.com nettside:
beskriv ('Test example.com', funksjon () før (funksjon (ferdig) client.init () .url ('http://example.com', ferdig);); beskriv , funksjon () det ('skal se riktig tittel', funksjon (ferdig) client.getTitle (funksjon (tittel) forvente (tittel) .to.have.string ('Eksempel Domene'); );)); det ('skal se kroppen', funksjon (ferdig) client.getText ('p', funksjon (p) forventer (tittel) .to.have.string ('for illustrative eksempler i dokumenter .)); ferdig ();;); etter (funksjon (ferdig) client.end (); ferdig ();;;); Du vil kanskje dele en klient initialisering over mange testfiler. Opprett en liten Node-modul for å initialisere og importere den til hver testfil:
client.js:
exports.client = require ('webdriverjs'). fjernkontroll (// Innstillinger; test.js:
var klient = krever ('./ klient'). klient; var forvent = kreve ('chai'). forvente; // Utfør tester Mocha test suiter utføres med mocha binære. Hvis du fulgte denne veiledningen og installert Mokka lokalt, bør du beskrive en full bane til binæret selv: node_modules / mocha / bin / mocha.
Som standard behandler Mocha en test som tar lengre tid enn to sekunder som feil. Gitt at vi faktisk initialiserer en nettleser og foretar en HTTP-forespørsel, må vi øke denne timeout til 5 eller 10 sekunder:
node_modules / mocha / bin / mocha test.js -t 10000
Hvis alt gikk i henhold til planen, bør du se utgang slik:
. ✔ 1 test fullført Når du har oppnådd de ønskede funksjonelle testresultatene, kan du vurdere å forbedre oppsettet ditt ytterligere.
To åpenbare veibeskrivelser er kontinuerlig integrering og distribuert selenprøving.
Målet ditt bør være å minimere tiden du bruker løpende tester.
Du vil kanskje bruke en fullautomatisk kontinuerlig integrasjonsserver, som vil kjøre testene når det trengs automatisk, og informere deg om noe går galt.
I en åpen kildekode-verden er rollen til en slik server dekket av Jenkins CI: en praktisk, kraftig, enkel å installere tjeneste, som vil kjøre testene når det trengs, utføre dem i hvilken som helst konfigurasjon du gir, og muligens kjøre mange mer byggrelaterte oppgaver, for eksempel distribusjon av koden til eksterne servere.
Alternativt, hvis du føler deg eventyrlystne, kan du eksperimentere med et nytt prosjekt, kalt GitLab CI, som tilbyr mindre funksjoner, men ser bedre ut og er integrert med GitLab, en selvbetjent GitHub klon.
I alle fall må målet ditt være å minimere tiden du bruker løpende tester. I stedet bør testene kjøres automatisk og bare informere deg om noe går galt.
Selen har en rekke implementeringsbegrensninger. For eksempel kan du ikke kjøre mer enn noen få nettlesere på samme maskin som skal testes med Selen.
I tillegg vil du legge merke til at når du har mange tester, kan kjører alle dem bli en langvarig prosess. Selv om kontinuerlig integrering delvis lindrer dette problemet, vil du kanskje likevel kjøre noen tester parallelt på forskjellige maskiner.
Til slutt vil du snart legge merke til at du vil teste forskjellige nettlesere på forskjellige operativsystemer. Og mens testkoden din i teorien kan snakke med forskjellige Selen-servere, når du vokser litt, trenger dette oppsettet sentralisering.
Selen Grid oppsett forsøker å gi nøyaktig det. I stedet for å ha en Selen-server kontroller en haug med nettlesere på en maskin, har du en Selen-server, som styrer flere Selenno-noder, som bare styrer noen få nettlesere på ett enkelt operativsystem.
Den resulterende stakken, selv om den ikke er trivial, i virkeligheten, er ganske enkel. Tilsetningen av PhantomJS til Selen-slutten gjør at vi kan begynne å bruke Selen uten mye innledende investeringer, for eksempel å sette opp grafiske testservere.
Bruken av JavaScript som testmotor sikrer at våre tester blir holdt relevante i sammenheng med webutvikling i overskuelig fremtid.
