Kodėl apskritai kalbame apie naršyklės automatizavimą?
Prieš kelis metus, kai tik pradėjau dirbti su automatizuotu testavimu, mano kolega pasakė: „Jei dar ranka testuoji tą patį scenarijų dešimtą kartą, tai ne tu valdai projektą, o projektas valdo tave.” Šie žodžiai iki šiol skamba ausyse. Naršyklės automatizavimas – tai ne tik apie testavimą, nors dažniausiai būtent čia jis ir taikomas. Tai apie tai, kaip sutaupyti laiko, sumažinti klaidų, ir leisti žmonėms užsiimti kūrybiškesniais dalykais nei nuolatinis mygtukų spaudymas.
Selenium ir TestCafe – du skirtingi požiūriai į tą pačią problemą. Selenium yra tarsi veteranas, kuris matė viską ir turi atsakymą į bet kokį klausimą (kartais per daug sudėtingą). TestCafe – jaunesnis, šviežesnis, su modernesniu požiūriu. Bet kuris iš jų geresnis? Atsakymas, kaip dažnai IT pasaulyje, skamba: „priklauso”.
Selenium: senas, bet auksas
Selenium egzistuoja nuo 2004-ųjų, ir tai jau savaime yra įspūdinga. Per tą laiką jis tapo de facto standartu automatizuotam testavimui. Kai kas sako, kad Selenium yra kaip PHP – visi jį kritikuoja, bet pusė interneto ant jo veikia.
Vienas didžiausių Selenium privalumų – tai ekosistema. Yra Selenium WebDriver, Selenium Grid, Selenium IDE. Galite rasti biblioteką beveik bet kuriai programavimo kalbai: Java, Python, C#, Ruby, JavaScript. Dokumentacijos – kiek tik širdis geidžia. Stack Overflow pilna atsakymų į bet kokį klausimą, kurį galite sugalvoti.
Tačiau štai kur prasideda smagumas: Selenium reikalauja nemažai papildomo darbo. Pirma, jums reikia WebDriver. Testuojate Chrome? Reikia ChromeDriver. Firefox? GeckoDriver. Safari? SafariDriver. Ir šie draiverai turi atitikti jūsų naršyklės versiją, kitaip viskas subyrės kaip kortų namelis.
// Selenium su Node.js
const {Builder, By, Key, until} = require('selenium-webdriver');
async function example() {
let driver = await new Builder().forBrowser('chrome').build();
try {
await driver.get('http://www.google.com');
await driver.findElement(By.name('q')).sendKeys('selenium', Key.RETURN);
await driver.wait(until.titleIs('selenium - Google Search'), 1000);
} finally {
await driver.quit();
}
}
Matote tą kodą? Jis atrodo gana paprastas, bet tai tik viršūnė ledkalnio. Realybėje jums dar reikės susikonfigūruoti aplinkos kintamuosius, įdiegti teisingą WebDriver versiją, galbūt sukurti Docker konteinerį, jei norite stabilumo CI/CD pipeline’e.
TestCafe atėjo į žaidimą
TestCafe pasirodė 2016-aisiais kaip šviežias vėjas. Pagrindinė idėja buvo paprasta: pašalinti visą tą konfigūracijos košmarą ir leisti žmonėms tiesiog rašyti testus. Ir, tiesą sakant, jiems tai pavyko.
Didžiausias TestCafe privalumas – jokių WebDriver’ių. Viskas veikia per Node.js ir tiesiogiai bendrauja su naršykle. Įdiegėte TestCafe? Puiku, galite pradėti rašyti testus. Nereikia jaudintis dėl ChromeDriver versijos, nereikia konfigūruoti kelio iki vykdomųjų failų, nereikia verkti naktimis, kai CI/CD pipeline’as vėl sugedo dėl kažkokios nesuderinamumo problemos.
// TestCafe testas
import { Selector } from 'testcafe';
fixture `Mano pirmasis testas`
.page `http://www.google.com`;
test('Paieškos testas', async t => {
await t
.typeText('input[name="q"]', 'testcafe')
.pressKey('enter')
.expect(Selector('title').innerText).contains('testcafe');
});
Pažiūrėkite į šį kodą. Jis skaitomas beveik kaip paprasta anglų kalba. TestCafe naudoja fixture ir test struktūrą, kuri atrodo intuityviai. Selektoriai veikia iš karto, be jokių papildomų importų ar konfigūracijų.
Našumo ir stabilumo klausimai
Čia prasideda įdomesni dalykai. Selenium yra greitesnis – bent jau teoriškai. Jis tiesiogiai bendrauja su naršykle per WebDriver protokolą, kuris yra optimizuotas greičiui. Tačiau praktikoje šis skirtumas dažnai nėra toks akivaizdus, ypač jei testuojate įprastą web aplikaciją.
TestCafe turi įdomų mechanizmą: jis injektuoja savo skriptus į puslapį ir per juos atlieka veiksmus. Tai reiškia, kad kartais jis gali būti šiek tiek lėtesnis, bet mainais gauname didesnį stabilumą. TestCafe automatiškai laukia, kol elementai taps prieinami, kol animacijos baigsis, kol AJAX užklausos grįš. Selenium to nedaro – jums patiems reikia rašyti visus tuos wait ir until sakinius.
Dirbu projekte, kur turime apie 500 automatizuotų testų. Kai naudojome Selenium, maždaug 10-15% testų periodiškai „flakindavo” – kartais praeidavo, kartais ne, dažniausiai dėl timing problemų. Perjungę į TestCafe, šis skaičius nukrito iki 2-3%. Tai nereiškia, kad TestCafe yra tobulas, bet jo įtaisyti laukimo mechanizmai tikrai padeda.
Kalbų palaikymas ir ekosistema
Jei jūsų komanda rašo Java arba Python, pasirinkimas akivaizdus – Selenium. TestCafe dirba tik su JavaScript/TypeScript. Tai gali būti privalumas arba trūkumas, priklausomai nuo situacijos.
Aš asmeniškai mėgstu TypeScript, todėl man TestCafe su TypeScript yra tiesiog malonumas. Gauname visą type safety, autocompletion, refactoring palaikymą. Bet jei jūsų backend komanda rašo Java ir nori patys prižiūrėti testus, versti juos mokytis JavaScript gali būti sunkus pardavimas.
Selenium ekosistema yra milžiniška. Yra Page Object Model bibliotekos, reporting įrankiai, integracijos su visais įmanomais test runner’iais. TestCafe ekosistema mažesnė, bet auga. Yra oficialių ir community sukurtų pluginų, integracijos su populiariais CI/CD įrankiais, reporting sprendimų.
Debugging ir kūrėjo patirtis
Čia TestCafe tikrai šviečia. Jie turi puikų debugging režimą, kur galite pristabdyti testą bet kuriame taške ir interaktyviai tyrinėti, kas vyksta. Galite naudoti Chrome DevTools, žiūrėti į konsolę, tikrinti elementus.
test('Debugging pavyzdys', async t => {
await t
.typeText('#username', 'testuser')
.debug() // Testas sustos čia
.click('#submit');
});
Selenium debugging’as yra… sudėtingesnis. Galite naudoti įprastus debugger’ius savo kalbai, bet naršyklės būsenos tyrinėjimas reikalauja daugiau rankinio darbo. Dažnai baigiesi rašydamas Thread.sleep() (Java atveju) arba time.sleep() (Python), kas yra baisus antipattern’as, bet kartais tiesiog reikia pamatyti, kas vyksta.
TestCafe taip pat turi puikią screenshot ir video įrašymo funkciją. Galite automatiškai įrašyti kiekvieno testo vykdymą, kas neįtikėtinai padeda, kai testas failina CI/CD aplinkoje, bet lokaliai veikia puikiai (klasikinis „works on my machine” scenarijus).
Paralelinis vykdymas ir skalabilumas
Selenium Grid yra galingas įrankis, leidžiantis vykdyti testus keliose mašinose, skirtingose naršyklėse, net skirtingose operacinėse sistemose. Tai yra branduolinis Selenium privalumas dideliems projektams. Galite turėti Grid hub’ą ir prie jo prijungti dešimtis node’ų, kiekvienas su skirtingomis naršyklėmis ir konfigūracijomis.
TestCafe taip pat palaiko paralelų vykdymą, bet paprasčiau. Galite tiesiog nurodyti, kiek concurrent browser instance’ų norite:
testcafe chrome:headless tests/ -c 3
Šis komandas paleis tris Chrome instance’us ir paskirstys testus tarp jų. Paprasta, efektyvu, be jokių papildomų konfigūracijų. Tačiau jei jums reikia tikrai didelio masto – šimtų browser instance’ų skirtinguose serveriuose – Selenium Grid vis dar yra galingesnis sprendimas.
Kaina ir mokymosi kreivė
Abu įrankiai yra open source ir nemokami, tad tiesioginio kainų palyginimo nėra. Bet yra „paslėptų” kainų – laiko, kurį praleidžiate mokydamiesi, konfigūruodami, prižiūrėdami.
Selenium mokymosi kreivė yra statesne. Reikia suprasti WebDriver architektūrą, išmokti teisingai naudoti laukimus, susipažinti su įvairiomis strategijomis elementų radimui. Jei kas nors jūsų komandoje anksčiau nėra dirbęs su Selenium, tikėkitės kelių savaičių įsivažiavimo periodo.
TestCafe yra draugiškesnis pradedantiesiems. Dokumentacija aiški, pavyzdžiai veikia iš karto, klaidos pranešimai informatyvūs. Naujas žmogus gali pradėti rašyti paprastus testus per kelias valandas. Bet tai nereiškia, kad TestCafe yra „žaisliukas” – jis turi daug advanced funkcionalumo, kurį galite išnaudoti, kai prireikia.
Kas gi realiai veikia geriau?
Dirbau su abiem įrankiais gamybinėse aplinkose, ir štai ką pastebėjau: Selenium yra geresnis pasirinkimas, kai jums reikia maksimalaus lankstumo ir kontrolės. Jei testuojate sudėtingą enterprise aplikaciją su specifinėmis reikalavimais, jei jūsų komanda jau turi Selenium expertise, jei naudojate ne-JavaScript kalbą – eikite su Selenium.
TestCafe yra geresnis, kai norite greitai pradėti, kai stabilumas yra svarbesnis už paskutinį našumo procentą, kai jūsų komanda dirba su JavaScript/TypeScript. Jis taip pat puikiai tinka mažesnėms ir vidutinėms komandoms, kurios neturi atskirų QA automation inžinierių ir nori, kad regular developeriai galėtų lengvai rašyti testus.
Viename projekte mes naudojame abu. Selenium – kritiniams end-to-end testams, kurie vykdomi naktimis ir tikrina visą sistemą įvairiose naršyklėse. TestCafe – greitesniems smoke testams, kurie vykdomi po kiekvieno deploy’o ir turi greitai pasakyti, ar viskas veikia. Tai nėra standartinis approach’as, bet mums jis veikia.
Praktinis patarimas: pradėkite su TestCafe, jei dar neturite automation infrastruktūros. Jis leis greitai gauti value ir įrodyti automation naudą komandai. Vėliau, jei prireiks, visada galėsite migruoti į Selenium arba naudoti abu kartu. Bet jei jau turite veikiančią Selenium infrastruktūrą ir komandą, kuri ją pažįsta – nėra stiprios priežasties keisti, nebent susiduriate su konkrečiomis problemomis, kurias TestCafe spręstų geriau.
Galiausiai, abu įrankiai yra tik priemonės. Svarbiausia yra ne tai, kurį framework’ą pasirinksite, o kaip organizuosite savo testus, kaip prižiūrėsite kodą, kaip integruosite automation į savo development procesą. Geras testas, parašytas Selenium, visada bus geresnis už blogą testą, parašytą TestCafe, ir atvirkščiai.
