Playwright CI/CD pipeline: kaip paleisti automatinius testus po kiekvieno pakeitimo

Playwright CI/CD pipeline leidžia automatinius testus paleisti ne rankiniu būdu, o automatiškai po kodo pakeitimo, pull request, merge arba prieš release. Tai vienas svarbiausių žingsnių, jeigu norite, kad testų automatizavimas realiai padėtų komandai, o ne liktų tik atskiru techniniu įrankiu.

Playwright testai ypač gerai tinka CI/CD procesui, nes jie gali veikti headless režimu, palaiko kelias naršykles, generuoja HTML, JUnit, screenshot, video ir trace ataskaitas bei leidžia greitai analizuoti nepavykusius testus.

Šiame straipsnyje paaiškinsime, kaip praktiškai planuoti Playwright testų paleidimą pipeline procese, kada juos leisti, kokius testus rinktis pirmiausia, kaip publikuoti ataskaitas ir kaip išvengti flaky testų problemų.

Jei dar tik pradedate su Playwright, pirmiausia verta perskaityti: kaip pradėti su Playwright nuo nulio. Jei domina platesnis CI/CD kontekstas, skaitykite: CI/CD testų integracija su Azure DevOps .

Kodėl Playwright testus verta leisti CI/CD pipeline?

Automatizuoti testai turi didžiausią vertę tada, kai jie paleidžiami reguliariai. Jeigu testai paleidžiami tik rankiniu būdu, komanda gali juos pamiršti, paleisti per vėlai arba pastebėti klaidas tik prieš pat release.

CI/CD pipeline išsprendžia šią problemą: testai paleidžiami automatiškai, rezultatai matomi visai komandai, o nepavykę testai tampa aiškiu signalu, kad pakeitimą reikia peržiūrėti.

• klaidos aptinkamos greičiau;
• mažėja rankinio regresinio testavimo poreikis;
• komanda saugiau dirba su pull request'ais;
• lengviau nuspręsti, ar pakeitimą galima merge'inti;
• testų rezultatai lieka pipeline istorijoje;
• release procesas tampa labiau prognozuojamas.

Kada paleisti Playwright testus?

Gera Playwright CI/CD strategija nėra vienas pipeline visiems atvejams. Skirtingi testų rinkiniai turėtų būti paleidžiami skirtingu metu.

1. Pull request metu

Pull request pipeline turi būti greitas. Jo tikslas – patikrinti, ar pakeitimas nesugadino svarbiausių sistemos dalių. Čia geriausia leisti trumpą smoke testų rinkinį arba kelis kritinius vartotojo scenarijus.

Jeigu PR testai trunka per ilgai arba dažnai krenta dėl nestabilumo, komanda pradeda juos ignoruoti. Todėl PR testai turi būti trumpi, stabilūs ir aiškiai prižiūrimi.

2. Po merge į pagrindinę šaką

Po merge į pagrindinę šaką galima paleisti platesnį testų rinkinį. Čia jau galima įtraukti daugiau UI, API ar integracinių testų, nes šis procesas nebūtinai turi būti toks trumpas kaip PR validacija.

3. Prieš deployment

Prieš diegiant į testavimo, staging ar produkcinę aplinką verta paleisti kritinius testus, kurie patvirtina, kad sistema gali būti saugiai išleista.

Tokie testai dažniausiai apima prisijungimą, pagrindinį vartotojo kelią, svarbiausias formas, mokėjimą, užsakymą ar kitą verslui kritinį funkcionalumą.

4. Nightly regression

Ilgesni regresiniai testai dažnai netinka kiekvienam pull request, nes jie gali per daug sulėtinti darbą. Tokius testus geriau paleisti pagal grafiką, pavyzdžiui, naktį.

Nightly pipeline leidžia reguliariai tikrinti platesnę sistemos dalį, netrukdant kasdieniam kūrimo procesui.

Kokius Playwright testus integruoti pirmiausia?

Pradėti geriausia ne nuo didžiausio testų kiekio, o nuo didžiausios vertės. Pirmasis Playwright CI/CD etapas turėtų būti mažas, stabilus ir aiškus.

• prisijungimo testas;
• pagrindinio puslapio arba dashboard atidarymas;
• pagrindinis vartotojo kelias;
• formos užpildymas ir išsaugojimas;
• užsakymo arba mokėjimo proceso patikrinimas;
• kritinės rolės arba leidimų patikrinimas;
• smoke testai po deployment.

Apie tai, kaip pasirinkti gerus elementų lokatorius, skaitykite: Playwright lokatoriai: kaip rašyti stabilius testus.

Minimalus Playwright pipeline pavyzdys

Žemiau pateiktas paprastas Azure DevOps YAML pavyzdys Node.js projektui su Playwright testais. Jis įdiegia priklausomybes, paruošia naršykles, paleidžia testus ir publikuoja rezultatus.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '20.x'
  displayName: 'Install Node.js'

- script: npm ci
  displayName: 'Install dependencies'

- script: npx playwright install --with-deps
  displayName: 'Install Playwright browsers'

- script: npx playwright test
  displayName: 'Run Playwright tests'

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results/*.xml'
    failTaskOnFailedTests: true
  condition: succeededOrFailed()
  displayName: 'Publish test results'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: 'playwright-report'
    artifact: 'playwright-report'
  condition: succeededOrFailed()
  displayName: 'Publish Playwright report'

Šis pavyzdys yra bazinis. Realiame projekte dažnai papildomai reikės aplinkos kintamųjų, prisijungimų, testų duomenų, skirtingų aplinkų, secret'ų ir kelių testų rinkinių.

Playwright reporteriai CI/CD aplinkoje

Kad Azure DevOps galėtų parodyti testų rezultatus, verta įjungti JUnit reporterį. HTML reportas naudingas detalesnei analizei, o JUnit rezultatai patogūs pipeline testų suvestinei.

reporter: [
  ['html'],
  ['junit', { outputFile: 'test-results/results.xml' }]
]

Taip pipeline gali publikuoti tiek struktūruotus testų rezultatus, tiek pilną Playwright HTML ataskaitą.

Kaip publikuoti screenshot, video ir trace failus?

Vien tik žinoti, kad testas nepraėjo, dažnai neužtenka. Komandai reikia greitai suprasti, kodėl testas nepavyko. Tam padeda Playwright artefaktai.

• screenshot – parodo, kaip atrodė ekranas klaidos metu;
• video – leidžia pamatyti visą testų vykdymo eigą;
• trace – padeda detaliai analizuoti veiksmus, tinklo užklausas ir DOM būseną;
• HTML report – leidžia patogiai peržiūrėti testų rezultatus naršyklėje.

Šiuos failus verta publikuoti kaip pipeline artefaktus, ypač kai testai vykdomi CI/CD aplinkoje ir programuotojas negali tiesiogiai matyti naršyklės.

Smoke, regression ir full testų rinkinių atskyrimas

Viena svarbiausių praktikų – nesumaišyti visų testų į vieną didelį rinkinį. Testus verta suskirstyti pagal paskirtį.

Smoke testai

Trumpi testai, kurie patikrina, ar sistema apskritai veikia. Jie turi būti stabilūs ir greiti. Juos verta leisti pull request arba prieš deployment.

Regression testai

Platesnis testų rinkinys, kuris tikrina, ar nauji pakeitimai nesugadino esamo funkcionalumo. Tokius testus galima leisti po merge arba naktį.

Full test suite

Pilnas testų rinkinys dažnai būna ilgesnis, todėl nebūtinai turi būti paleidžiamas kiekvienam pakeitimui. Jis labiau tinka prieš svarbius release arba pagal grafiką.

Kaip pažymėti skirtingus Playwright testų rinkinius?

Playwright leidžia testus grupuoti pagal pavadinimus, projektus arba tag'us. Pavyzdžiui, galite turėti atskirus smoke ir regression testų paleidimus.

npx playwright test --grep @smoke

Tada pipeline gali paleisti tik trumpą smoke rinkinį pull request metu, o platesnį regression rinkinį – po merge arba pagal grafiką.

npx playwright test --grep @regression

Tokia struktūra padeda išlaikyti greitą pipeline ir kartu neprarasti platesnio testų padengimo.

Kaip sumažinti flaky testų problemą?

Flaky testai yra viena dažniausių priežasčių, kodėl komandos praranda pasitikėjimą automatizavimu. Jei testas kartais praeina, kartais nepraeina be aiškios priežasties, jis neturi būti kritinis deployment gate.

Kad Playwright testai būtų stabilesni CI/CD aplinkoje:

• naudokite stabilius lokatorius, pvz. role, label, test id;
• venkite fiksuotų laukimų, pvz. timeout ar sleep;
• leiskite Playwright naudoti auto-waiting mechanizmus;
• paruoškite testų duomenis prieš kiekvieną testą;
• venkite testų priklausomybės vienas nuo kito;
• naudokite trace, screenshot ir video analizei;
• atskirkite nestabilius testus nuo kritinio smoke rinkinio.

Daugiau apie struktūrą skaitykite: Playwright Page Object Model.

Dažniausios Playwright CI/CD klaidos

• per daug testų paleidžiama kiekviename pull request;
• pipeline trunka per ilgai ir stabdo komandą;
• nepublikuojami reportai ir artefaktai;
• testai priklauso nuo nestabilių duomenų;
• naudojami silpni CSS arba XPath lokatoriai;
• flaky testai stabdo deployment;
• nėra aiškaus žmogaus, atsakingo už testų priežiūrą;
• testų rezultatai ignoruojami, jei jie nepraeina.

Dažniausiai problema nėra Playwright įrankis. Problema yra tai, kaip testai parinkti, kaip jie integruoti į pipeline ir kaip komanda reaguoja į jų rezultatus.

Kada Playwright testai turi stabdyti deployment?

Deployment turėtų stabdyti tik tie testai, kuriais komanda tikrai pasitiki ir kurie tikrina kritinius scenarijus. Jei testas nestabilus arba tik informacinis, geriau jo nenaudoti kaip pagrindinio deployment gate.

• stabdyti deployment: smoke testai, prisijungimas, pagrindinis vartotojo kelias, kritiniai API testai;
• nestabdyti deployment: ilgi regresiniai testai, eksperimentiniai testai, nestabilūs testai;
• leisti atskirai: pilna regresija, cross-browser testai, ilgi E2E scenarijai.

Kaip suprasti, ar Playwright pipeline duoda vertę?

Pipeline vertė matuojama ne testų kiekiu, o tuo, ar jis padeda komandai greičiau ir saugiau dirbti. Geras Playwright pipeline turi būti pakankamai greitas, stabilus ir aiškus.

• kiek laiko trunka pipeline;
• kiek klaidų randama prieš release;
• kiek testų yra stabilūs;
• kiek laiko užima klaidos analizė;
• ar komanda pasitiki testų rezultatais;
• ar sumažėjo rankinio regresinio testavimo poreikis;
• ar sumažėjo kritinių klaidų produkcijoje.

Susijusios temos

• CI/CD testų integracija su Azure DevOps
• Kaip pradėti su Playwright
• Playwright lokatoriai
• Playwright Page Object Model
• Kada verta automatizuoti testus
• Testų automatizavimas

DUK apie Playwright CI/CD pipeline

Ar Playwright tinka CI/CD pipeline?

Taip. Playwright gerai tinka CI/CD pipeline, nes gali veikti headless režimu, palaiko kelias naršykles ir generuoja HTML, JUnit, screenshot, video bei trace ataskaitas.

Kokius Playwright testus verta leisti pull request metu?

Pull request metu verta leisti trumpus ir stabilius smoke testus arba kritinius vartotojo scenarijus. Ilgi regresiniai testai dažniausiai geriau tinka naktiniam arba atskiram pipeline.

Ar visi Playwright testai turi stabdyti deployment?

Ne. Deployment turėtų stabdyti tik kritiniai ir stabilūs testai. Nestabilius, eksperimentinius arba ilgus regresinius testus geriau leisti atskirai.

Kaip publikuoti Playwright reportą Azure DevOps pipeline?

Playwright HTML reportą galima publikuoti kaip pipeline artefaktą naudojant Azure DevOps užduotį PublishPipelineArtifact. JUnit rezultatus galima publikuoti su PublishTestResults užduotimi.

Kaip sumažinti flaky testus CI/CD aplinkoje?

Reikia naudoti stabilius lokatorius, vengti fiksuotų laukimų, tinkamai paruošti testų duomenis, atskirti testus vieną nuo kito ir analizuoti screenshot, video bei trace failus.

Reikia pagalbos su Playwright CI/CD pipeline?

Padedame komandoms paruošti stabilų Playwright CI/CD procesą: nuo testų struktūros ir smoke rinkinio iki Azure DevOps pipeline, reportų, artefaktų ir flaky testų mažinimo.

Jei jūsų testai jau parašyti, bet dar nėra patikimai paleidžiami CI/CD procese, verta sutvarkyti pipeline strategiją ir testų vykdymo procesą.

Susisiekite →