Playwright vai Selenium? Automaattinen odotus vähentää odotuskoodia

|Kirjoittaja: QUASAn toimitus|4 min lukuaika| 1
Playwright vai Selenium? Automaattinen odotus vähentää odotuskoodia

Uudelle JavaScript- tai TypeScript-käyttöliittymätestisarjalle Playwright on perusteltu lähtökohta, jos tiimi haluaa vähentää erillistä odotuskoodia ja sen tukemat selaimet riittävät. Playwrightin toimintokelpoisuustarkistukset odottavat ennen napsautusta, että kohde näkyy, pysyy paikallaan, vastaanottaa osoitintapahtuman ja on käytettävissä. Näille ehdoille ei tarvitse kirjoittaa omaa odotusta jokaisen napsautuksen edelle.

Selenium on usein luontevampi perusta, jos hyväksyntätesti on ajettava oikeassa Safarissa tai organisaatiolla on toimiva WebDriver-kanta. Seleniumin selainajurien ja kielisidosten luettelo sisältää Applen tukeman SafariDriverin sekä JavaScript-, Python-, Java-, .NET- ja Ruby-sidokset. Sen odotusmallissa testin kirjoittajan on kuitenkin ilmaistava tarvittavat ehdot tarkemmin: Seleniumin odotusohje erottaa elementin löytämistä koskevan implisiittisen odotuksen ehtokohtaisesta eksplisiittisestä odotuksesta ja varoittaa sekoittamasta niitä.

Mitä automaattinen odotus korvaa?

Playwrightin etu näkyy tilanteessa, jossa painike ilmestyy, vapautuu tai lakkaa liikkumasta vasta aiemman toiminnon jälkeen. Paikantimeen kohdistuva napsautus odottaa tarvittavia tiloja määräaikaan asti ja epäonnistuu aikakatkaisuun, elleivät ehdot täyty. Myös Playwrightin uudelleen yrittävät väittämät voivat odottaa esimerkiksi tekstin tai näkyvyyden muutosta. Siksi tavallinen testipolku tarvitsee vähemmän erikseen kirjoitettuja synkronointirivejä.

Toimintokelpoinen painike ei silti kerro, onko sovelluksen taustalla tekemä tallennus valmis tai näkyykö oikea lopputulos sivulla. Testin on edelleen määriteltävä havaittava lopputila, jota väittämä odottaa. Jos napsautuksessa käytetään Playwrightin force-asetusta, osa toimintokelpoisuuden tarkistuksista ohitetaan; esimerkiksi osoitintapahtuman vastaanottoa ei silloin tarkisteta samalla tavalla.

Seleniumin implisiittinen odotus vaikuttaa elementin etsimiseen koko istunnossa ja päättyy heti, kun elementti löytyy. Löytyminen ei yksin takaa, että elementti näkyy tai että seuraava toiminto onnistuu. Eksplisiittinen odotus voi kohdistua juuri tarvittavaan ehtoon, kuten näkyvyyteen. Se antaa testille täsmällisen synkronointipisteen, mutta ehto on kirjoitettava sinne, missä sitä tarvitaan. Kiinteä viive on huonompi korvike: liian lyhyt viive altistaa virheelle ja tarpeettoman pitkä hidastaa onnistunuttakin ajoa.

Missä selainvaatimus muuttaa valinnan?

Safari ja WebKit erottuvat toisistaan selaintuen vertailussa, vaikka Playwright kattaa WebKitin.

Playwrightin selaindokumentaatio kattaa Chromiumin, Firefoxin ja WebKitin sekä asennetut Google Chrome- ja Microsoft Edge -selaimet. Näin yleinen usean selainmoottorin testaus onnistuu samalla työkalulla. Selainmoottorin nimi ei kuitenkaan yksin määritä hyväksyntätestin kohdetta: Playwrightin WebKit-versio ei ole asennettu Apple Safari, eikä sen muokattu Firefox-versio ole tavallinen Firefox-jakelu.

WebKitillä voi etsiä Safariin liittyviä renderöintiongelmia, mutta tietyn Safari-version, macOS-ympäristön tai alustasta riippuvan ominaisuuden vaatimus puoltaa testiä oikealla Safarilla. Tällöin Seleniumin SafariDriver on suorempi vaihtoehto. Pelkkä Chrome- tai Edge-vaatimus ei ratkaise työkalua, koska molemmilla voi ajaa näitä selaimia. Vaatimuksessa on syytä erottaa toisistaan selainmoottorien kattavuus ja nimenomaisen selainjakelun testaus.

Myös kielivaatimus on täsmennettävä. Se, että organisaatiossa käytetään useita ohjelmointikieliä, ei vielä kerro, pitääkö kaikkien tiimien käyttää samaa testikehystä vai riittääkö yhteinen selainajo. Jos nykyiset WebDriver-testit, ajurit ja etäajoympäristö palvelevat jo eri kielillä työskenteleviä tiimejä, niiden korvaaminen on oma siirtymätyönsä. Uuden erillisen JavaScript- tai TypeScript-sarjan valinta voidaan tehdä ilman oletusta, että koko olemassa oleva kanta siirretään samalla kertaa.

Mitä läpimenomittaus osoittaa?

Seleniumin ja Playwrightin läpimenomittauksissa HP- ja Dell-koneet vaihtuivat ajokertojen välillä.

Julkaistun tutkimuksen läpimenotaulukossa kello 8.00 HP-koneen Selenium-ajo saavutti 1,41 toimintoa sekunnissa ja Dell-koneen Playwright-ajo 1,16; kello 8.15 koneiden vaihtuessa Playwright sai HP:lla 1,33 ja Selenium Dellillä 1,31, ja iltapäivän Dellillä tehty Playwright-ajo päättyi aikakatkaisuun. Samanaikaiset tulokset mitattiin siis eri koneilla. Kun koneet vaihtuivat, vaihtui myös mittaushetki.

Kokeessa Python-skriptit suorittivat lähes samanlaisia toimintoja yhdellä verkkosivustolla. Koneissa käytettiin samaa Chrome-versiota, mutta niiden suoritin- ja tallennusratkaisut erosivat. Mittauksissa tarkasteltiin myös etusivun, linkkien ja kuvien latausaikoja. Nämä suureet eivät vastaa koko käyttöliittymätestisarjan valmistumisaikaa, eikä yksittäisten onnistuneiden ajojen nopeus yksin kuvaa testien vakautta.

Läpimenotaulukon yksikkö on toimintoa sekunnissa, kun taas tutkimuksen myöhempi läpimenoa käsittelevä vertailu esittää kuvien latausaikoja sekunteina. Näitä suureita ei voi yhdistää yhdeksi työkalujen nopeuseroksi. Aineisto kertoo, että tulos riippui mitatusta toiminnosta, koneesta ja ajokerrasta; siitä ei seuraa yleistä lupausta Playwrightin tai Seleniumin nopeammasta testisarjasta omassa jatkuvassa integraatiossa.

Päätösmatriisi kolmelle lähtötilanteelle

Valinnassa kannattaa painottaa ensin pakollista selainta ja nykyisen testikannan arvoa, sitten odotuskoodin ylläpitoa. Mitattu läpimeno ratkaisee vasta, kun vertailu koskee samaa sovellusta ja hyväksyttävää selainkokoonpanoa.

  • Uusi JavaScript- tai TypeScript-sarja: aloita Playwrightista, jos Chromium, Firefox, WebKit tai sen tukemat Chrome- ja Edge-kanavat täyttävät vaatimukset. Toimintokelpoisuuden tarkistukset ja uudelleen yrittävät väittämät vähentävät käsin kirjoitettavia odotuksia. Lyhyempi testi ei kuitenkaan yksin tarkoita nopeampaa kokonaisajoa, joten suorituskyky on mitattava omilla käyttäjäpoluilla.
  • Monikielinen organisaatio: selvitä, mitkä tiimit todella jakavat testikoodia, ajureita ja etäajoympäristöä. Seleniumin kielisidokset ja olemassa oleva WebDriver-infrastruktuuri voivat tehdä sen jatkamisesta käytännöllistä, etenkin jos hyväksyntä vaatii oikeaa Safaria. Uusi, muusta kannasta erillinen testisarja voi silti käyttää Playwrightia; organisaation kielten määrä ei yksin ratkaise uuden sarjan työkalua.
  • Vanha WebDriver-kanta: säilytä toimivat testit Seleniumissa ja tarkista epävakaista kohdista, odottaako testi juuri oikeaa ehtoa. Koko kannan siirtäminen vaatii testien, selainajon ja tulosten vertailun uudelleen. Playwrightista saatava hyöty on tässä punnittava siirtymätyötä vasten, eikä automaattinen odotus itsessään korjaa sovelluksen epäselviä lopputiloja.

Kun suorituskyky ratkaisee tasaisen valinnan

Jos molemmat työkalut täyttävät selainvaatimukset, vertailun kohteeksi sopii sama käyttäjäpolku samalla selaimella, ajokoneella ja sovellusversiolla. Myös rinnakkaisten ajajien määrä ja onnistumisen ehdot on pidettävä samoina. Ajojärjestyksen vaihtelu auttaa havaitsemaan, suosivatko palvelimen kuormitus tai välimuisti toista työkalua.

Kirjaa erikseen onnistuneiden ajojen kesto, aikakatkaisut ja koko sarjan valmistumisaika. Odotuskoodin määrä kertoo ylläpitotyöstä, kun taas valmistumisaika kertoo ajon kapasiteetista; ne vastaavat eri kysymyksiin. Valinta on perusteltu, kun hyväksyttävä selainajo, testien toimintavarmuus ja tiimin ylläpitokustannus ovat selvillä samasta ympäristöstä.

Lue myös:

Jaa:

Tilaa uutiskirjeemme

Saat tuoreimmat Web3-, tekoäly- ja kryptouutiset suoraan sähköpostiisi.

0