AutoTest Pro AutoTestPro

Playwright Page Object Model (POM): kaip rašyti lengvai prižiūrimus E2E testus

Augant Playwright E2E testų kiekiui, projektai dažnai pradeda kentėti nuo pasikartojančio kodo: tie patys prisijungimo žingsniai, identiški locatoriai, dubliuojami formų veiksmai ir sunkiai prižiūrimi scenarijai.

Būtent čia atsiranda Page Object Model (POM). Šis dizaino pattern leidžia atskirti UI logiką nuo pačių testų ir padeda kurti stabilesnę, aiškesnę bei lengviau plečiamą Playwright framework architektūrą.

Kas yra Page Object Model (POM)?

Page Object Model (POM) yra testavimo architektūros principas, kuriame kiekvienas puslapis arba UI komponentas turi savo klasę. Vietoje tiesioginio darbo su locatoriais testuose, visi veiksmai perkeliami į page object klases.

Pavyzdžiui:

  • prisijungimo puslapis turi LoginPage klasę;
  • lentelė turi TableComponent klasę;
  • modal langas turi ModalComponent klasę;
  • testas naudoja metodus vietoje tiesioginių selector'ių.

Tokiu būdu testai tampa orientuoti į verslo scenarijus, o ne į DOM detales.

Kodėl Playwright projektuose verta naudoti POM?

Mažuose projektuose POM gali atrodyti perteklinis, tačiau augant testų kiekiui jis tampa vienu svarbiausių stabilumo elementų.

Page Object Model (POM) ypač naudingas kai:

  • turite daugiau nei 20–30 E2E scenarijų;
  • keli testuotojai arba programuotojai dirba su tais pačiais testais;
  • UI dažnai keičiasi;
  • norite sumažinti flaky testų kiekį;
  • projektas turi ilgalaikę regression strategiją.

Didžiausias privalumas — UI pakeitimus dažnai reikia taisyti tik vienoje vietoje.

Paprastas Playwright POM pavyzdys

Vietoje locator'ių tiesiogiai teste: 

await page.getByRole('textbox', { name: 'Email' }).fill('user@test.com');
await page.getByRole('textbox', { name: 'Password' }).fill('secret');
await page.getByRole('button', { name: 'Prisijungti' }).click();

galima turėti LoginPage klasę: 

await loginPage.login('user@test.com', 'secret');

Testas tampa trumpesnis, aiškesnis ir lengviau skaitomas net žmonėms, kurie nepažįsta visų UI detalių.

Rekomenduojama Playwright projekto struktūra

Nėra vienos tobulos struktūros, tačiau praktikoje dažniausiai gerai veikia toks modelis:

  • pages/ — page object klasės pagal puslapius;
  • components/ — bendri UI komponentai;
  • tests/ — tik scenarijai ir assert logika;
  • fixtures/ — login, setup ir shared context;
  • utils/ — helper funkcijos ir techninė logika.

Tokia struktūra padeda išvengti chaoso augant testų bazei.

Kas turi būti Page Object klasėje?

Gera Page Object klasė turi būti orientuota į konkretaus puslapio veiksmus.

Dažniausiai joje būna:

  • locatoriai;
  • vartotojo veiksmai;
  • helper metodai;
  • kartais nedidelės UI validacijos.

Tačiau svarbu neperkrauti page object klasės visa verslo logika arba dideliais assert'ais. Testai turi išlikti aiškūs ir suprantami.

Dažniausios klaidos naudojant POM

1. „God class“ problema

Viena klasė su šimtais metodų tampa sunkiai prižiūrima. Geriau skaidyti logiką pagal puslapius arba komponentus.

2. Per ankstyvos abstrakcijos

Daugelis komandų pradeda kurti labai sudėtingą framework dar neturėdamos realių problemų. Dažnai paprastesnė struktūra pradžioje veikia geriau.

3. Dubliuojami locatoriai

Jei tas pats locatorius kopijuojamas į kelis failus, UI pakeitimai tampa labai brangūs.

4. Testų logikos slėpimas

Kartais komandos paslepia visą verslo scenarijų page object klasėse ir testai tampa nebesuprantami. Testas turi išlikti skaitomas.

POM ir Playwright locatoriai

Geriausias rezultatas pasiekiamas kartu naudojant:

  • tvarkingą Page Object Model (POM);
  • stabilius Playwright lokatorius;
  • aiškią locatorių strategiją.

Jei locatoriai yra trapūs, net geriausia POM architektūra neišgelbės flaky testų.

Todėl rekomenduojama pirmiausia naudoti:

  1. getByRole
  2. getByLabel
  3. getByText
  4. getByTestId

CSS ir XPath reikėtų naudoti tik išimtiniais atvejais.

Kada nereikia sudėtingo POM?

Jei projektas turi tik kelis testus arba yra trumpalaikis, pilnas Page Object Model (POM) gali būti perteklinis.

Tokiais atvejais dažnai užtenka:

  • paprastų helper funkcijų;
  • minimalios struktūros;
  • gerų locator'ių;
  • tvarkingo testų išdėstymo.

Svarbiausia — ne framework sudėtingumas, o testų stabilumas ir komandos produktyvumas.

Kaip pradėti diegti POM esamame projekte?

Nebūtina perrašyti visų testų iš karto. Geriausia pradėti nuo dažniausiai naudojamų scenarijų:

  1. prisijungimo;
  2. vartotojo kūrimo;
  3. mokėjimo;
  4. filtravimo;
  5. administravimo veiksmų.

Sukurkite pirmus page object failus ir palaipsniui perkelkite locatorius bei veiksmus iš testų.

Dažniausiai net dalinis POM įvedimas jau stipriai pagerina projekto kokybę.

DUK apie Playwright Page Object Model (POM)

Ar POM būtinas Playwright projektuose?

Ne visada, tačiau didesniuose projektuose jis labai padeda mažinti priežiūros kaštus ir stabilizuoti testų bazę.

Ar Page Object Model mažina flaky testus?

Netiesiogiai taip. POM leidžia centralizuoti locatorius ir lengviau prižiūrėti UI pokyčius, tačiau stabilūs locatoriai vis tiek išlieka svarbiausias faktorius.

Ar verta naudoti komponentų klases?

Taip. Header, modalai, lentelės, dropdown'ai ir kiti pasikartojantys UI blokai dažnai labai tinka component object struktūrai.

Kuo skiriasi POM nuo helper funkcijų?

Helper funkcijos dažniausiai sprendžia technines užduotis, o POM modeliuoja realų UI ir vartotojo veiksmus.

Susiję straipsniai

Reikia pagalbos su Playwright framework?

Padedame komandoms kurti stabilią Playwright architektūrą, diegti Page Object Model (POM) ir mažinti flaky E2E testų kiekį.

Susisiekite dėl Playwright automatizavimo →