Kuinka dokumentoida loppupään hyväksymistestejäsi

Lähde

Tämä artikkeli toimii "miten" -ohjeena Selenium Docker -kuvien käyttämiseen CodeceptJS: n ja Express-palvelimen rinnalla.

Siinä käsittelemme:

  • Mikä on E2E-hyväksyntätestaus?
  • Miksi käyttää Dockeria?
  • Löysästi kytketyt testaustyökalut
  • Testausvälineiden kerrokset
  • Koeprojektin luominen

E2E-hyväksyntätestaus

Hyväksyntätestaus on vaihe tyypillisessä ohjelmistokehitysprosessissa. Se kattaa testit sen selvittämiseksi, täyttääkö tuote yleiset vaatimukset ja onko se ”hyväksytty” toimitusvalmiina. Se on tyypillisesti viimeinen testausvaihe ennen tuotteen luovuttamista tuotantoon. Tähän voi kuulua käyttäjäpohjaisia ​​hyväksymistestejä, yrityspohjaisia ​​hyväksymistestejä tai jopa alfa- / beetatestauksia.

End-to-End (E2E) -testaus on yksi hyväksymistestauksen toteutus. Se on lähestymistapa hyväksymistestaukseen, mutta termit eivät ole synonyymejä. Sen avulla voidaan testata sovelluksen virtausta alusta loppuun nähdäkseen, toimiiko sovellus suunnitellulla tavalla. Verkkosovelluksen tapauksessa siihen sisältyy käyttäjän skenaarion määrittäminen ja jokaisen käyttäjän suorittaman vaiheen testaaminen. Testi epäonnistuu, jos skenaariota ei suoriteta onnistuneesti.

Tämän prosessin automatisoimiseksi on olemassa erilaisia ​​työkaluja, jotka simuloivat käyttäjän vuorovaikutusta sovelluksen kanssa.

Miksi Docker?

E2E-testien luomista ja suorittamista pidetään usein hiukan monimutkaisena prosessina. Se vaatii paljon asennusta, joka voi silti helposti epäonnistua, kun sitä käytetään eri koneissa tai CI (jatkuva integrointi) -ympäristössä. Eri selainten ja WebDrivers-ohjelmien asentaminen ja ylläpito sekä paikallisia että CI-testejä varten vie aikaa. Ja vaikka se olisi valmis, se voi silti epäonnistua yksinkertaisten ongelmien vuoksi, kuten jos näytön resoluutio kehittäjän paikallisissa koneissa tai CI: ssä on erilainen.

Myös Dockerin vakioetuja sovelletaan: sinun ei tarvitse käsitellä käyttöjärjestelmän yhteensopivuutta tai olla asentamassa riippuvuuksia. Selenium Server -sovelluksen suorittamiseen tarvitaan Java asennettuna (tai ainakin käynnistettävä / lopetettava nimenomaisesti). Expressin suorittamiseen tarvitset Node.js, ja Chromelle tarvitset itse Chromen sekä ChromeDriverin.

Dockeria käytettäessä nämä riippuvuudet poistuvat. Käytät vain erilaisia ​​säilytysastioita, jotka jo sisältävät nämä, jotka toimivat täsmälleen samalla tavalla riippumatta siitä, millä koneella niitä käytetään. Kun sitten ajattelet, kuinka helppoa on rakentaa Docker CI: hen, testiprosessin dokumentoinnista tulee ilmeinen valinta.

Löysästi kytketyt testaustyökalut

E2E-testejä kirjoitettaessa on saatavana useita kehyksiä, ja tulokkaalle voi olla vaikea tietää mitä valita ja sijoittaa aikaa. Jos valitset väärän, olet hukannut paljon aikaa.

Täältä CodecepJS tulee kuvaan. CodeceptJS on testausjärjestelmä, joka käyttää skenaariopohjaista, käyttäytymislähtöistä kehitystyötä (BDD), jossa on API-kieli, jota muiden kuin insinöörien on helppo ymmärtää ja käyttää. Ehkä vielä tärkeämpää on kuitenkin, että se on taustanagnostinen. Se on kirjoitettu useiden suosittujen testauskirjastojen (esimerkiksi WebDriverIO tai Puppeteer) päälle, ja sen yksi korkean tason sovellusliittymä kommunikoi valitsemasi kanssa. Luojat uskovat sen

Testejäsi ei pidä sitoa suoritusmoottoriin. Valitessasi Seleeni vai Puppeteer, testien pitäisi näyttää melkein samanlaisilta. Jos tunnet (myöhemmin) yhden moottorin rajoitukset, voit helposti vaihtaa testisi toiseen.

Testausvälineiden kerrokset

Jotkut jokaisessa kerroksessa saatavilla olevista tuotteista, joilla simuloidaan käyttäjän vuorovaikutusta selaimen kanssa

Tarkastellaan alhaalta ylöspäin suuntautuvaa lähestymistapaa tarkastelemalla kuinka jokainen kerros rakentuu viimeiselle.

Aluksi kannattaa viitata Seleeniin, pitkäaikaiseen projektiin aktiivisesti käytetyillä työkalusarjoilla, jotka nykyään koostuvat Selenium WebDriveristä, Gridistä, Serveristä ja IDE: stä. Näitä työkaluja luotaessa he ovat asettaneet monia teollisuusstandardeja, jotka usein on hämmentävästi nimetty niiden seleenituotteiden perusteella, joista he ovat tulleet. Tämä näkyy 'Selenium WebDriver' -tuotteessa ja sen kehittämisessä perustetussa 'WebDriver-johdotusprotokollassa'. Sovellettavat esitetään tarkemmin alla.

selain

Mikä tahansa selain: Chrome, Firefox, Internet Explorer, Safari, Opera ja niin edelleen. Dokumentaatiossa kutsutaan usein 'käyttäjäagentiksi'.

W3C: n WebDriver-johdotusprotokolla

WebDriver-lankaprotokolla on alusta ja kielivapaa tapa toimia vuorovaikutuksessa selainten kanssa. Se määrittelee yleisen RESTful-verkkopalvelun, joka käyttää JSON: ää HTTP: n kautta pyyntö / vastaus-pareissa. Sen avulla DOM-elementtejä voidaan manipuloida ulkoisesta lähteestä, samalla kun se selaa myös verkkosivuja, käyttäjän syöttämiä tietoja, JavaScriptin suorittamista ja paljon muuta.

Alun perin Selenium kirjoitti Selenium WebDriver -sovellukselle, tämä protokolla on nyt saavuttanut toimittajan luonnoksen vaiheessa tullakseen viralliseksi W3C-standardiksi.

Muut protokollat ​​poistuvat, mutta niitä ei käsitellä tässä yksityiskohtaisesti. Kaikki selitykset edellyttävät taustaohjelmaa, joka toteuttaa WebDriver-lankaprotokollan.

Toinen merkittävä protokolla on Puppeteerin käyttämä Chrome DevTools -protokolla. Puppeteer ei käytä Selenium Server -sovellusta, ja mukana toimitetaan Chromiumin viimeisin versio, joka on tarkoitettu paikalliseen käyttöön. Jos haluat suorittaa Puppeteerin Dockerissa, voit joko käyttää CodeceptJS-kuvaa (joka tulee Puppeteerin ja painajaisen mukana) tai seurata virallista opasta luoda mukautettu kuva, joka tukee sitä.

Selaimen WebDrivers

Nämä ovat selainkohtaisia ​​WebDriver-johdotusprotokollan toteutuksia, esimerkiksi ChromeDriver Chromelle tai GeckoDriver Firefoxille. Jokainen toimii itsenäisenä palvelimena vastaanottaa pyyntöjä asiakkaalta, jossa WebDriver-sovellusliittymää käytetään (yleensä missä testit pidetään). Jotta voidaan kommunikoida aiotun selaimen kanssa, oikea WebDriver-toteutus on asennettava.

Seleeni-palvelin

Jos testejä ajetaan samalla koneella, joka ne on määritelty, käytetty asiakaspuolen WebDriver API -sovelluksen toteutus (kuvattu alla) voi kommunikoida suoraan selaimen WebDriver -sovelluksen kanssa eikä Seleeni-palvelinta vaadita.

Jos testit kuitenkin suoritetaan toisella koneella, joko CI: ssä, Seleeni Grid -asetuksessa useiden koneiden tai virtuaalikoneiden (VM) välillä, etätestausalustalla, kuten BrowserStack tai SauceLabs, tai Dockerissa, sitten Seleeni Palvelinta käytetään. Se toimii välityspalvelimena välittääksesi pyynnöt asiakaspuolen WebDriver API: lta oikealle selaimen WebDriverille, ja välittää vastauksen takaisin selaimesta.

Kuten myöhemmin näemme, kone voidaan myös vaihtaa konttiksi.

Asiakaspuolen WebDriver-toteutus

Asiakaspuolen WebDriver-lankaprotokolla toteutetaan useilla työkaluilla. Tässä protokollaa voidaan pitää sovellusliittymänä pyyntöjen lähettämiseksi selaimelle yllä kuvattujen kerrosten kautta. Monet protokollaa käyttävät työkalut ovat kokonaisia ​​kehyksiä, kuten WebDriverIO, jotka sisältävät omat testisuunnittelijat.

Muita toteutuksia ovat: alkuperäinen Selenium WebDriver, Protractor, Appium ja muut.

Kunkin kirjaston tavoitteena on saavuttaa samat tulokset, mutta hieman erilaisilla painopisteillä ja API-toteutuksilla. Tämä voi olla yhtä perustiedot kuin Protractorin selain.get (URL) verrattuna WebDriverion selaimeen.url (URL).

Yksi sovellusliittymä hallitsemaan niitä kaikkia

Kuten tämän osan alussa kuvailtiin, CodeceptJS alkaa tässä vaiheessa. Se viittaa muihin asiakaspuolen WebDriver-protokollan (tai muihin) toteutuksiin ”auttajina” ja antaa sinun määrittää haluamasi avustaja käytettäessä yhtä API-kieltä. CodeceptJS ei välitä siitä, mitä protokollaa valittu avustaja käyttää.

WebDriverIO, Puppeteer, Protractor, Nightmare ja Appium ovat kaikki nykyisiä käytettävissä olevia auttajia.

CodeceptJS: ssä edellinen komento olisi I.amOnPage (url) riippumatta siitä, mikä avustaja valittiin. Tämä tarkoittaa, että jos halusit vaihtaa taustaohjelmasi johonkin muihin tuettuihin avustajiin, testejäsi ei tarvitse kirjoittaa uudelleen. Oletus API-menetelmiä on mahdollista korvata tai lisätä mukautettujen luokkien kautta, jos haluat.

Koeprojektin luominen

Niin monien kerrosten kanssa tämä alkaa kuulostaa monimutkaiselta, mutta CodeceptJS: n alustuskomentosarjan ja Docker-kuvien välillä on nopeasti toimiva esimerkki.

Mitä me tuotamme

Kaksi konttia käytetään nyt, vaikka sitä voidaan pidentää

Kirjoitamme CodeceptJS: ssä yksinkertaisen testin, joka määrittelee WebDriverIO-taustaohjelman auttajan, joka kommunikoi etäselaimen kanssa erillisen Firefox-Docker-säilön sisällä. Käytämme pika- "hello world" -sovellusta, mutta se voidaan korvata millä tahansa haluamallasi sovelluksella.

Pian tarvitaan vain kaksi komentoa Dockerized-sovelluksen ja kaikkien testipakettien suorittamiseen

Kun kaikki on valmis, pystymme suorittamaan vain kaksi komentoa testien suorittamiseen:

  • telakointiasema - rakenna
  • docker suorittaa -sovelluksen npm-testin: e2e

Ajamalla kahdessa vierekkäin olevassa pääteikkunassa näemme konttien käyvän ja testin suorittavan reaaliajassa.

edellytykset

  • Telakoitsija, mistä tahansa koneesta olet kehittämässä.
  • Voit myös asentaa Node.js, & npm -sovelluksen paikallisiin kehittämis- ja virheenkorjaustoimintoihin, mutta nämä voidaan myös suorittaa täysin Dockerissa.

Tiedoston rakenne

Tuotamme alla olevan tiedostorakenteen. Voit nähdä toimivan esimerkin Githubista.

| - .gitignore
| - lähtö /
| - Dokkeritiedosto
| - app.js
| - telakka-sävelt. symboli
| - paketti.json
| - pack-lock.json
| - e2eTests /
    | - yhteinen_test.js
    | - docker.conf.js

riippuvuudet

Ensin luomme paketin.json, jossa Express on riippuvuus ja CodeceptJS ja WebDriverIO dev riippuvuuksina.

{
  "nimi": "esimerkki-itsenäinen-Firefox",
  "versio": "1.0.0",
  "kuvaus": "Esimerkki E2E-testaamisesta",
  "skriptit": {
    "start": "node app.js",
    "test: e2e": "codeceptjs suorittaa - vaiheet - verbose --config =. / e2eTests / docker.conf.js"
  },
  "riippuvuudet": {
    "express": "^ 4.16.3"
  },
  "devDependencies": {
    "codeceptjs": "^ 1.2.0",
    "webdriverio": "^ 4.12.0"
  }
}

Olemme sisällyttäneet myös kaksi skriptiä, yhden lisättävän Express-sovelluksen suorittamiseen (npm run start) ja toisen CodeceptJS-testimme suorittamiseen (npm run test: e2e).

codeceptjs suorittaa - vaiheet - verbose --config =. / e2eTests / docker.conf.js

- vaiheet ovat hienoja näytön tulostamiseen terminaalissa, kun testit ovat käynnissä, kun taas - verbose laajentaa yksityiskohtaisuutta entisestään. --verbosea ei todennäköisesti tarvita vakiona, mutta se on hyvä esimerkin toiminnan kannalta. --config näyttää meille polun taustan määritystiedostoon, jota tässä tapauksessa pidetään erillisessä e2eTests-hakemistossa.

Sovelluksemme

Seuraavaksi tarvitsemme sovelluksen testaamiseksi. Tätä varten käytämme Express “hello world” -sovellusta sovelluksesta.js.

const express = vaatia ('express');

const app = express ();

app.get ('/', (req, res) => res.send ('Hello World!'));

const server = app.listen (3000, () => {
    const-portti = palvelin.osoite () .portti
    console.log (`Esimerkki sovelluksen kuuntelusta portissa $ {port}`)
 })

Voit tarkastella tätä käyttämällä npm run start ja siirtymällä sitten localhost: 3000 selaimeesi.

Testaa kokoonpano

CodeceptJS vaatii kaksi tiedostoa, määritystiedoston ja testitiedoston. Testitiedosto on erittäin yksinkertainen: se testaa, että sovellusta voidaan käyttää, tallentaa kuvakaappauksen ja tarkistaa, että teksti "Hei" näkyy sivulla.

Ominaisuus ('Perustesti');

Skenaario ('navigoi kotisivulle', I => {
  I.amOnPage (http: // app: 3000 ");
  I.saveScreenshot ( 'frontpageScreenshot.png');
  I.see ( 'Hei');
});

Ensimmäinen merkki siitä, että käytämme useita Docker-säilöjä, näkyy tässä sovelluksen käytössä: 3000 sijaan localhost: 3000. localhost voidaan ymmärtää vain yhden säilön sisällä. Jos komentoa ajetaan toisesta säilöstä (tässä tapauksessa Firefox toisessa Seleeni-säilössämme), se tarvitsee tarkemman viitteen. Voisimme käyttää ensimmäisen säilön IP-osoitetta suoraan, mutta säilön nimen käyttäminen on paljon helpompaa lukea.

Sovellus on tässä tapauksessa sovellusta käyttävän säilön nimi, joten voimme käyttää sovellusta: 3000. Älä huolestu, jos et vielä noudata tätä, näet kuinka docker-compose.yml on rakennettu, se auttaa.

Tarvitsemme myös päämääritystiedoston. Tämä voidaan kirjoittaa JSON tai JS, mutta tässä käytetään JS. Katsotaanpa tätä:

export.config = {
  testit: './*_test.js', // kuinka tietää, mitkä tiedostot ovat testitiedostoja
  output: './output', // mihin kuvakaappaukset tallennetaan
  auttajat: {
   WebDriverIO: {// mitä taustaohjelman apua käytetään
     url: 'http: // sovellus: 3000', // perus URL-osoite aloittamiseen
     isäntä: 'firefox-container', // yksilöi seleenin juokseva sijainti
     selain: 'firefox', // sarja asetusvaihtoehtoja
     smartWait: 5000,
     waitForTimeout: 10000,
     toivottu kyky: {// demosovellukselle, jota emme halua
         acceptInsecureCerts: totta, huolehtia SSL-sertifikaateista
     }
   },
  },
  nimi: 'codeceptjs-docker',
};

Asettaminen Docker

Palaamalla yllä olevaan ”Tuotamme” -osiossa olevaan kaavioon voidaan nähdä, että käytämme kahta Docker-säilöä. Heidän on oltava tietoisia toisistaan ​​ja kyettävä kommunikoimaan. Yksi sisältää sovelluksemme ja testimme, toinen Selenium Server, GeckoDriver ja Firefox, joten emme tarvitse Firefoxia asennettuna paikalliselle koneellemme.

Docker Compose on työkalu ”monisäiliöisten Docker-sovellusten määrittelemiseen ja ajamiseen”. Se käynnistää Docker-säilöt komennolla docker-compose ylös ja pysäyttää ne docker-compose-alaspäin. Jos käyttäjän määrittämää Docker-tiedostoa käytetään, --build -sovellusta käytetään sen luomiseen, joko ensimmäisen kerran suoritettaessa docker-compose up -sovellus tai jos Docker-tiedostoon on tehty muutoksia. docker-compose.yml on tiedosto, joka määrittelee, mitä ylös-komento tekee.

Seuraava askel on luoda tämä docker-compose.yml. Se on voimakkaasti riippuvainen syvennyksestä.

versio: "2" // mitä kirjoittamasi syntaksin versiota käytät
palvelut:
  sovellus:
    container_name: app // explicit, jotta voimme käyttää tätä sovellukselle: 3000
    rakentaa:. // itse määritelty Docker-tiedosto, katso alla
    portit: // paljastaa portin 3000 (missä express suoritetaan)
      - "3000: 3000" muihin kontteihin ja paikallisille
    riippuu_on: selain
      - Firefox-säilö
    tilavuudet: // kartat, joten muutokset näihin näkyvät
      - ./e2eTests:/e2eTests
      - ./pakkaus.json:/paketti.json
      - ./pakkaus-lock.json:/paketti-lock.json
      - ./.gitignore:/.gitignore
      - ./app.js:/app.js

  firefox-container: // tarkastelemme tätä alla
    kontti_nimi: firefox-säilö
    kuva: seleeni / itsenäinen-Firefox: 3.12.0-americium
    volyymit:
      - / dev / shm: / dev / shm
    portit:
      - "4444: 4444"

Käytämme Selenium Server -sovellusta, ohjaimia ja selainta varten ennalta määritettyä kuvaa, joka on saatavana julkisesta Docker Hubista ja jota kutsutaan seleeni / itsenäinen-Firefox. Määritämme, minkä version haluamme, 3.12.0-americium. Jos emme määrittäneet tätä, viimeisintä kuvaa käytetään oletuksena (mikä ei ole huono asia). Kuten neuvoa, määritämme sen jakamaan isännän muistin estääksemme selaimen kaatumista, ja paljastamalla portti 4444, oletus Seleeni-portti. Yhdistämme tämän myös porttiin 4444 paikallisella koneellamme, jotta voimme vierailla localhostissa: 4444 / wd / hub / static / resource / hub.html selaimessa.

Emme käytä pelkästään jonkun muun rakentamaa sovellussäiliötämme, vaan kirjoitamme Docker-tiedoston määritelläksesi kuinka sovelluksemme on rakennettu. Samoin kuin seleeni-firefox-säilö, paljastamme tässä tapauksessa portin, 3000, koska tässä Express toimii oletusarvoisesti. Kartoittamalla tämä käyttämällä kuvaa 3000: 3000, voimme vierailla localhost: 3000: ssa sovelluksen ollessa käynnissä Dockerissa nähdäksesi sen paikallisessa selaimessamme.

Dockerfilemme käyttää julkista solmua: hiilikuva perustana, asettaa työhakemiston, kopioi joitain tiedostoja paikallisesta koneesta säilöön, suorittaa npm-asennuksen, jotta säilöllä olisi kaikki tarvittavat riippuvuudet, ja suorittaa sitten määrittämämme npm start -komennon. .

FROM solmusta: hiili
WORKDIR ./
COPY ./package.json ./package-lock.json ./app.js ./
RUN npm asennus
CMD ["npm", "start"]

Tämä tarkoittaa, että kun docker-compose up --build ajetaan, se noudattaa näitä vaiheita, jolloin sovelluksemme on valmis ja käynnissä portissa 3000.

Huomaa: --build-lippu tarvitaan vain ensimmäistä kertaa, kun docker-compose-up suoritetaan, tai jos Docker-tiedostoon tai sen vaiheisiin on tehty muutoksia. Jos esimerkiksi lisäisimme toisen riippuvuuden pakettiin.json, Docker ei tietäisi siitä, jos emme rakentaisi kuvaa uudelleen, koska npm install suoritetaan Docker-tiedostossa.

Juoksutestit

Meillä on nyt yksinkertainen sovellus, sille kirjoitetut testit ja Docker Compose -määritykset, jotka ajavat sekä sovelluksemme, Seleeni Server- että Firefox-sovelluksen.

Voimme aloittaa kaikki nämä käyttämällä docker-compose up --build -sovellusta.

Voit suorittaa komentoja käynnissä olevan Docker-säilön sisällä, docker-suoritusta voidaan käyttää toisesta pääteikkunasta. Muoto on:

telakoitsijaohjelma

Käytämme seuraavaa komentoa:

docker suorittaa -sovelluksen npm-testin: e2e

Voimme nyt nähdä testimme käynnissä ja nähdä jokaisen vaiheen sen suorittaessa! Tästä eteenpäin voimme laajentaa testimme tekemiä, lisätä ylimääräisiä testejä (päättää tiedostonimet _test.js-tiedostossa) ja käyttää niitä samoilla kahdella komennolla. Asennusta ei tarvita enää.

Sinulla on nyt helposti laajennettava E2E-testausasetus, johon voidaan luottaa toimimaan samalla tavalla riippumatta siitä, missä koneessa sitä käytetään. Se kirjoitettiin API-komennoilla, jotka ymmärtävät helposti sekä kehittäjät että muut kuin kehittäjät. Nyt jäljellä on vain päättää, mihin käyttäytymiseen sovelluksesi tulee pystyä, ja testata se!

Loppusanat

SeleniumHQ tuottaa myös Docker-kuvia Chromen testausta varten ja kuvia Selenium Grid -sovelluksen käyttämiseksi useiden Chromen ja Firefox-esiintymien käyttämiseen kerrallaan.

CodeceptJS: llä on myös ohjeet CodeceptJS: n suorittamiseksi Dockerissa, joten sitä ei tarvitse määrittää riippuvuudeksi sovelluksessasi.

Teknisempi, mutta silti aloittelijakuvaus Dockerin toiminnasta on nähtävissä kirjoittamasi viestin ensimmäisessä osassa, jonka otsikko on Aloittelijan opas Amazonin joustavan säiliön huoltopalveluun.

Kiitos, että luit

Päivittää:
Kirjoitin äskettäin CodeceptJS e2e -testien räätälöinnin kaikille, jotka etsivät seuraavia vaiheita monimutkaisten sovellusten testaamiseksi.

voimavarat

  • Github of CodeceptJS Docker -esimerkkejä
  • CodeceptJS QuickStart -opas
  • Selenium WebDriver -arkkitehtuuri
  • Seleeni WebDriver Flow