Tässä artikkelissa tarjotaan pikainen opas tehokkaiden end-to-end -testien kirjoittamiseen jest-puppeteerilla, korostaen asennusprosessia, yleisimmin käytettyjä API:ita ja käytännön testitilanteita yksinkertaisen tehtävälistasovelluksen avulla.
Osana sitoutumistamme Logton laadun varmistamiseen ja jatkuvaan parantamiseen, käytämme jest-puppeteerilla end-to-end -automaattista testausta. Tämä mahdollistaa Logton kehityksen nopean toistamisen ilman keskeytyksiä.
Tässä artikkelissa jaamme kokemuksemme tehokkaiden jest-puppeteer testiskriptien kirjoittamisesta yksinkertaisen tehtävälista-sovelluksen avulla. Tavoitteenamme on auttaa sinua pääsemään nopeasti alkuun jest-puppeteer -testikoodin kirjoittamisessa omiin projekteihisi.
End-to-end -testaus on tapa varmistaa, että sovelluksesi toimii oikein käyttäjän näkökulmasta. Tämä saavutetaan kahden tärkeän työkalun avulla: Jest ja Puppeteer.
Jest on suosittu JavaScript-testauskehys, joka tarjoaa käyttäjäystävällisen API:n testien ja väittämien kirjoittamiseen. Sitä käytetään laajalti yksikkö- ja integraatiotestaamiseen.
Puppeteer on Chrome-tiimin kehittämä Node.js-kirjasto, joka tarjoaa korkean tason API:n headless Chrome- tai Chromium-selainten hallintaan. Tämä tekee siitä ihanteellisen valinnan selaimen vuorovaikutuksen automatisointiin end-to-end -testeissä.
jest-puppeteer on Jest-asetus, joka mahdollistaa end-to-end -testauksen Puppeteerilla. Se tarjoaa suoraviivaisen API:n uusien selaininstanssien käynnistämiseen ja vuorovaikutukseen verkkosivujen kanssa niiden kautta.
Nyt kun sinulla on perusymmärrys tärkeimmistä työkaluista, mennään asennusympäristön luomiseen.
End-to-end -testausympäristön asettaminen jest-puppeteerilla on yksinkertainen prosessi, joka sisältää kolme päävaihetta:
Asenna riippuvuudet
Omassa projektissasi (tai luo uusi projekti) avaa terminaali ja suorita komento:
Siirry sitten node_modules/puppeteer -hakemistoon ja asenna Chromium (jota Puppeteer tarvitsee):
Määritä Jest
Seuraavaksi sinun on määritettävä Jest toimimaan saumattomasti Puppeteerin kanssa.
Luo Jest-konfiguraatiotiedosto (esim. jest.config.js) projektisi juurihakemistoon, jos sinulla ei ole sellaista. Tässä konfiguraatiotiedostossa määritä jest-puppeteer esiasetuksena:
Voit mukauttaa muita Jest-asetuksia tässä tiedostossa tarpeen mukaan. Lisätietoja Jest-määritysten mukauttamisesta voit lukea Jest-konfiguraatiosta.
Kirjoita testisi
Luo testitiedostot projektiisi, jotka nimetään yleensä .test.js -päätteellä. Jest löytää ja suorittaa nämä testitiedostot automaattisesti.
Seuraavissa vaiheissa tukeudumme Jestin, Puppeteerin ja jest-puppeteerin tarjoamiin API:hin, jotka auttavat meitä testeissämme.
Jest tarjoaa pääasiassa API:ita testien organisointiin ja odotettujen tulosten väittämiseen. Voit tutustua tarkkoihin yksityiskohtiin dokumentaatiosta.
Puppeteerin API:t on ensisijaisesti suunniteltu vuorovaikutukseen selainten kanssa, ja niiden tuki testaukseen ei välttämättä ole suoraviivaista. Voit viitata Puppeteerin dokumentaatioon ymmärtääksesi sen tarjoamat toiminnot. Seuraavissa testiesimerkeissämme käsittelemme joitain yleisiä käyttötapauksia.
Koska Puppeteerin API:t eivät alun perin olleet suunniteltu testaamista varten, niiden käyttäminen testien kirjoittamiseksi voi olla haastavaa. Jotta Puppeteer-testien kirjoittaminen olisi helpompaa, jest-puppeteer sisältää kirjaston nimeltä expect-puppeteer. Se tarjoaa joukon tiiviitä ja käyttäjäystävällisiä API:ita. Kirjasto esitellään sen dokumentaatiossa, joka esittelee erilaisia hyödyllisiä ominaisuuksia, kuten alla olevissa esimerkeissä:
Seuraavissa esimerkeissä yhdistämme näiden kirjastojen tarjoamia API:ita testauskäsikirjoitustemme suorittamiseen.
Nyt on aika aloittaa testikoodin kirjoittaminen yksinkertaisen tehtävälista-sovelluksen avulla.
Oletetaan, että meillä on yksinkertainen tehtävälista-sovellus, joka toimii osoitteessa http://localhost:3000, ja sen pääasiallinen HTML-koodi on seuraava:
Suorittaessamme end-to-end -testausta pyrimme kattamaan seuraavat skenaariot:
Kun käytämme sovelluksen URL-osoitetta, sovellus ja sen tiedot latautuvat oikein.
Kohteen tarkistuspainikkeen pitäisi olla klikattavissa.
Ulkoisen linkin klikkaaminen kohteen muistiinpanojen sisällä pitäisi avata linkki uuteen välilehteen.
Lomakkeesta voidaan lisätä kohde.
Myöhemmin kirjoitamme testikoodia näiden skenaarioden validoimiseksi.
Odota, että sovellus ja sen tiedot ovat latautuneet#
Pidämme, että sovellus on ladattu onnistuneesti, kun seuraavat ehdot täyttyvät:
Elementeillä, joiden ID on "app", pitäisi olla olemassa sivulla, kun käytät sovelluksen URL-osoitetta.
Sovelluksen sisällä olevien tietojen tulisi olla renderöity oikein.
Olemme kirjoittaneet seuraavan testikoodin:
Koodissa:
page.goto on vastaavaa kuin syöttäisit "http://localhost:3000" selaimeen, jolloin voit navigoida mihin tahansa URL:iin.
page.waitForSelector käytetään odottamaan, että tietty CSS-valitsin vastaa tiettyä elementtiä, ja vakio odotusaika on 30 sekuntia.
expect(page).toMatchElement on expect-puppeteer -kirjastosta, ja se on samanlainen kuin page.waitForSelector, mutta se myös tukee elementin tekstin vastaamista. Lisäksi toMatchElement:n oletus aikakatkaisu on vain 500ms.
Se saattaa vaikuttaa täydelliseltä ensisilmäyksellä, mutta kun tätä testiä suoritetaan ja se otetaan käyttöön CI-ympäristössä, se epäonnistuu satunnaisesti useiden suoritusten jälkeen. Virhesanoma osoittaa:
Virheilmoituksen ja tosiasian perusteella, että tämä testi läpäisee useimmiten, voimme päätellä, että sovelluksen pyytämät tiedot eivät aina palaa ensimmäisen 500 ms:n aikana sovelluksen latautumisen jälkeen. Siksi haluamme odottaa tietojen latautumista ennen väittämistä.
Tyypillisesti on kaksi yleistä lähestymistapaa tämän saavuttamiseksi:
Lisää väittämisen odotusaikaa
Virhesanomasta näemme, että toMatchElement:n oletus odotusaika on asetettu 500 ms:aan. Voimme lisätä odotusaikaa lisäämällä timeout-vaihtoehdon funktioon näin:
Tämä lähestymistapa voi vähentää epäonnistuneiden testien esiintymistä jossakin määrin, mutta se ei täysin ratkaise ongelmaa, koska emme voi varmaksi tietää kuinka paljon aikaa tietojen hakemiseen tarvitaan.
Siksi käytämme tätä lähestymistapaa vain silloin, kun olemme varmoja tarvittavasta odotusajasta, esimerkiksi skenaarioissa, joissa "työkaluvihje ilmestyy, kun hiiri leijuu elementin päällä yli 2 sekuntia."
Odota verkkopyynnön valmistumista ennen väittämän tekemistä
Tämä on oikea lähestymistapa. Vaikka emme ehkä tiedä, kuinka kauan tietopyyntö kestää, odottaminen verkkopyynnön päättymiseen asti on aina turvallinen valinta. Tässä vaiheessa voimme käyttää page.waitForNavigation({ waitUntil: 'networkidle0' }) odottaa verkkopyyntöjen päättymistä:
Tällä tavalla, ennen kuin suoritamme väittämän Sovellukselle ja sen ladatuille tiedoille, voimme varmistaa, että verkkopyynnöt on jo päättynyt. Tämä varmistaa, että testi tuottaa johdonmukaisesti oikeat tulokset.
Seuraavaksi testaamme kohteen sisäisen tarkastuspainikkeen klikkaamisen toiminnallisuutta.
Esimerkkisovelluksessa olemme huomanneet, että kaikki kohteet jakavat saman rakenteen. Heidän tarkastuspainikkeillaan on CSS-valitsin li[class$=item] > button, ja painikkeen teksti on aina "Tarkista". Tämä tarkoittaa, että emme voi suoraan määrittää, minkä kohteen tarkastuspainiketta klikataan. Tarvitsemme siis uuden ratkaisun.
Oletetaan, että haluamme klikata "Lue Logto aloittamisasiakirja" -kohteen tarkastuspainiketta. Voimme jakaa tämän kahteen vaiheeseen:
Saadaan ensin viittaus kyseiseen kohteeseen.
Klikataan sitten kyseisessä kohteessa olevaa tarkastuspainiketta.
Koodin mukaisesti käytämme toMatchElement-funktiota vastaamaan kohdetta, jonka itemName on "Lue Logto aloittamisasiakirja". Sitten käytämme readDocItem-viittausta klikata painiketta, jonka tekstisisältö on 'Tarkista' sen alapuolella.
On tärkeää huomata, että kun hankitaan readDocItem, käytettävä CSS-valitsin on li[class$=item]:has(div[class$=itemName]). Tämä valitsin vastaa kohteen juurituetta li, ei sen sisällä olevaa itemName:ää, koska aiomme myöhemmin klikata li-tunnisteen alla olevaa button-painiketta.
expect(readDocItem).toClick-käyttö on samanlainen kuin toMatchElement. Esimerkissä annamme { text: 'Tarkista' } vastaamaan edelleen painikkeen textContent:a. Voit kuitenkin valita, vastaako painikkeen tekstisisältöä tarpeidesi mukaan.
Odota, että ulkoinen linkki avataan uuteen välilehteen#
Seuraavaksi haluamme testata, voimmeko avata ulkoisen linkin uuteen välilehteen, kun klikkaamme sitä kohteen muistiinpanojen sisällä.
Esimerkkisovelluksessa olemme havainneet, että "Lue Logto aloittamisasiakirja" -kohteella on ulkoinen linkki Logto-asiakirjaan sen muistiinpanoissa. Tässä on meidän testikoodi:
Koodissa käytämme toClick-funktiota klikataksemme linkkiä itemNotesin sisällä.
Nyt haluamme testata kohteen lisäämisen toiminnallisuutta.
Meidän on täytettävä kohteen nimi ja kohteen muistiinpanot lomakkeeseen, klikattava "Lisää"-painiketta ja tarkistettava, näkyykö lisäämämme sisältö luettelossa:
Huomaat, että käytämme expect(page).toFill(inputSelector, content)-funktiota, joka korvaa kaikki syötteen sisällöt contentilla.
Jos haluat lisätä joitakin merkkejä syötteeseen korvaamatta nykyistä sisältöä, voit käyttää page.type(selector, content)-funktiota lisätäksesi haluamasi sisällön suoraan syötteeseen.
Kun meidän on täytettävä useita kenttiä lomakkeessamme, toFill:n kutsuminen useita kertoja ei ole kätevää. Tällaisessa tapauksessa voimme käyttää seuraavaa lähestymistapaa täyttääksemme kaiken sisällön yhdellä kerralla:
Annettava olion avain on syötteen name-attribuutti.
Olemme käsitelleet yksinkertaista esimerkkiä esitelläksemme yleisiä testaustarpeita ja vastaavia koodin kirjoitustekniikoita, kun käytät jest-puppeteer end-to-end -testaukseen. Toivomme, että se auttaa sinua nopeasti omaksumaan perusteet jest-puppeteer testikoodin kirjoittamisesta.
