Page Object model si organizarea testelor automate

Automatizarea anumitor cazuri si scenarii de test este un proces foarte important in contextul largit al testarii software (QA). Scrierea testelor automate in sine e un skill foarte important, care necesita cunostinte mai tehnice de programare si framework-uri dedicate ce ne ajuta sa „punem lucrurile in miscare”, precum Cypress sau Selenium.

Insa dincolo de faptul ca dezvoltam aceste teste cu anumite tool-uri, un alt aspect la fel de important in arhitectura acestor suite de automation este modul lor de organizare propriu-zisa: cate fisiere avem, ce scriem in fiecare fisier astfel incat sa putem sa accesam informatiile mai usor, cum grupam testele automate etc.

Ca in aproape orice sfera, si aici exista multe moduri in care putem sa organizam testele noastre automate. Unul din modurile cele mai cunoscute si folosite despre care vom discuta in continuare este Page Object model.

Ce este Page Object model (POM)?

Page Object Model, abreviat in cele mai multe locuri ca POM, reprezinta un mod prin care testerii isi structureaza framework-ul de testare. La inceput cand invatam despre testare software, este suficient sa ne scriem toate testele de exercitiu intr-un singur fisier, unele dupa altele, pentru ca numarul lor nu e foarte mare.

Dar pe masura ce ajungem sa lucram cu adevarat in testare si sa gestionam sute sau mii de teste automate, nu mai e deloc simplu sa cautam anumite functii, erori sau locatori intr-un singur fisier scris ca un bloc, ci trebuie sa ne organizam altfel. Degeaba avem sute de teste automate scrise daca ne este foarte greu sa le updatam sau sa le imbunatatim cand e cazul.

Aici intervine Page Object model. Dupa cum ii spune si numele, acest model presupune crearea unui framework de testare prin separarea in clase si obiecte a logicii de functionare a testelor si a elementelor web de UI cu care acestea interactioneaza. Pentru a intelege si aplica Page Object, e nevoie de niste cunostinte de programare mai avansate, inclusiv partea ce tine de OOP (Object-oriented prgramming).

Astfel, POM usureaza semnificativ munca de management a testelor automate. Ipotetic vorbind, daca intervine o eroare, ne putem da seama mai usor de unde provine (o functie scrisa gresit in logica, un locator ce s-a schimbat, un obiect care nu mai apare in UI-ul paginii web etc.), si sa corectam in consecinta.

Vrei sa inveti testare automata folosind Selenium & Python scriind teste bazate pe Page Object Model? Foloseste acest curs in limba Romana.

Cum se structureaza testele in Page Object model

Prima daca cand invatam sa scriem teste automate, de regula deschidem IDE-ul, setam o noua fila, si in functe de limbajul si framework-ul folosit, incercam sa automatizam anumite functionalitati de pe unele pagini web mai simple, pe care le cunoastem. Dupa ce scriem testele, dam ‘Save’ si acest fisier poate fi incarcat pe contul personal de GitHub, de exemplu.

Exemplu de teste automate fara a fi structurate in Page Object model

Nu e nimic gresit aici, insa pe masura ce lucrurile se complica, aplicarea unui model precum Page Object poate ajuta la o mai buna intelegere si structurare a testelor, chiar daca initial o sa para mai complicat, in special daca suntem la inceput cu invatatul.

Modelul Page Object a pornit si s-a dezvoltat dinspre zona instrumentului de automatizare Selenium, un tool extrem de puternic, versatil si cu multe upgrade-uri semnificative primite de-a lungul timpului, ce poate fi folosit cu multe limbaje de programare (Java, Python, C# etc.).

In cadrul unui context Page Object, testele noastre automate privite ca niste functii ce interactioneaza cu elementele de UI ale paginii web sunt organizate intr-o clasa care de regula defineste acel scenariu de testare (ex: Valid_Login). In cadrul acestei clase mari se pot define ulterior mai multe metode (= set de functii care executa in mod dedicate un anumit lucru), care de fapt sunt testele noastre ce sunt organizate mai unitar.

Elementele din pagina pot fi si ele organizate distinct, intr-o clasa separata, eventual chiar intr-un fisier separat, astfel incat daca exista vreo eroare legata de faptul ca s-a schimbat locatorul unui element (ex: s-a schimbat ID-ul acestuia sau Xpath-ul), atunci ne e mai usor sa il gasim si sa il fixam.

Exemplificarea Page Object model

Exemplificarea generala a modelului de structurare Page Object pentru testele automate este ilustrat in diagrama de mai jos, preluata de pe site-ul cu resurse de testare si nu numai Guru99.

Schema generala a Page Object model. Sursa: Guru99

In modelul din stanga este structurarea simplista, intr-un singur fisier cu o singura clasa practic, logica testelor (codul functional propriu-zis) este intercalat cu elementele din interfata paginii web. Este definit un test, definim variabilele in care stocam elementele de UI, si apoi pasii, ce facem cu aceste elemente si ce dorim sa asertam.

In partea dreapta este prezentat Page Object model, cu definirea a doua clase separate (aici ele sunt in acelasi fisier in IDE, dar pot fi si separate in 2 file diferite, dar nu ne complicam inca asa tare).

In clasa A sunt trecute separat si bine individualizat elementele de UI cu care urmeaza sa interactionam, le definim cat mai precis o singura data si apoi le refolosim de cate ori avem nevoie. In clasa B este scrisa logica de automatizare, adica testele automate propriu-zise cu pasii pe care ii facem rand pe rand, folosind obiectele din clasa A.  

Un exemplu concret de suita de teste automate organizata dupa modelul Page Object este reflectata mai jos. Avem definita o clasa (un bloc compact in codul nostru) in interiorul careia au fost create mai multe metode printre care cea de accesare a paginii, cele prin care adaugam niste valori in campurile de text si metoda care face submit formularului de login.

Exemplu simplu cu un test automat, structurat cu Page Object model – Pagina

In al doilea fisier gasim testul automat propriu-zis ce cuprinde apelarea/executarea metodelor definite in clasa paginii de mai sus.

Exemplu simplu cu un test automat, structurat cu Page Object model – Testul

Acesta organizare este mult mai clar decat daca am fi avut un singur fisier. Folosind Page Object Model, se pot discerne si vizualiza mult mai usor elementele paginii si testele propriu zise.

Concluzii

In incheiere, Page Object model reprezinta o modalitate practica foarte buna si folosita in organizarea suitelor de teste automate, care ajuta extrem de mult testerii sa faca un management mai bun al acestora.

Erorile pot fi identificate mai usor, nu e nevoie sa inspectam toate fisierele, si poate ajuta inclusive la modul in care sunt gandite scenariile de testare astfel incat sa fie usor gestionate cu timpul. Lucrurile pot devein sim ai complicate prin adaugarea de noi elemente in structura organizarii noastre de automation, si putem ajunge si la alte modele precum Page Factory.

Surse consultate

Una din sursele primare de informatie despre Page Object model este chiar pe site-ul de documentatie proprie al celor de la Selenium, framework-ul dinspre care s-a dezvoltat acest model.

Detalii suplimentare si exemple explicate sunt si pe BrowserStack si Guru99.

YouTube are si el extrem de multe tutoriale despre POM in diferite moduri, de exemplu cu Playwright sau cu Selenium.

Mircea-Gabriel Macarie

https://www.linkedin.com/in/mirceamacarie/

Tech enthusiast și QA engineer, membru al comunității Vlog De IT. Interesat de testare software (QA) în general, de User Experience și Web Development.

Related post

Leave a Reply

Your email address will not be published. Required fields are marked *