Robot Framework tippek: Saját lokátorok létrehozása SeleniumLibrary-ben

Amikor az XPath már nem a barátod

Tesztautomatizálóként néha szembesülhetünk azzal, hogy egy adott oldalon a DOM szerkezetet megnyitni olyan, mintha labirintusba kerülnénk. A szükséges XPath-ek és CSS szelektorok néha olyan hosszúak, hogy már a monitorod is panaszkodik, és inkább elrejtené őket. Ilyenkor (és persze egyéb esetekben is) jól jöhet, ha az általunk kitalált logikát használva egyszerűsíteni tudnánk az objektumok elérési útvonalain. Egyedi lokátorok használata ebben nyújthat nekünk segítséget.

Mi az a saját lokátor, és miért jó nekünk?

A saját lokátor egy automata eszköz, jelen esetben a SeleniumLibrary funkciója arra, hogy egyedi logika szerint történjen az oldalon található elemek azonosítása.

Mikor mondjuk azt, hogy „Elég volt az XPath-ből, jöjjön a saját lokátor”?

  • Amikor a használt xpath-ok hosszúak és folyton ugyanazokat a részeket tartalmazzák.
  • Ha bonyolult shadow DOM elemekkel kell foglalkozni
  • Ha a fejlesztők olyan egyedi paramétereket adtak, amiket ezzel a módszerrel egyszerűbb használni.

Például, ha egy oldalon az összes beviteli mezőnek van egy label-je, amiben a mező neve szerepel (például „Név”, „Email”), akkor ezt a labelt is használhatod a mező azonosításához. Így ahelyett, hogy hosszú XPath-eket írnál, egyszerűen azt mondod, hogy „az a mező kell, aminek a labelje ‘Név’!”. Ezt a logikát persze kód szinten Neked kell megvalósítanod, mert ez oldalstruktúra függő.

Hogyan csinálhatunk saját lokátort a Selenium Library-ben?

A Selenium Library-ben van egy add location strategy nevű varázsszó kulcsszó, ami lehetővé teszi ezt nekünk. Ezt általában a suite setup-ban szoktuk megadni, hogy a hozzá tartozó összes teszthez használni tudjuk. Ez a kulcsszó két dolgot vár tőlünk: egy nevet a lokátorunknak, és egy másik kulcsszót, ami a háttérben lefut, amikor ezt a lokátort használjuk.

A lokátorunk neve bármi lehet. A mögötte futó kulcsszó pedig 4 argumentumot vár: browser, locator, tag, constraints. Azért ezeket várja, mert ezek kötelező paraméterei az egyedi lokátor kulcsszavunknak. Ezek közül a legfontosabb a locator, ami tartalmazza a lokátor alkotáshoz szükséges információt. A kulcsszó magja pedig olyan logikát tartalmaz, amilyet csak akarunk. Használhatunk javascriptet, paraméteres xpath-t, stb stb.. A lényeg, hogy visszaadjuk vele magát az objektumot.

Egy kód többet mond minden szónál

Egy példa a használatra

Egy bankot szimuláló tesztoldalon fogunk kitölteni contact us űrlapot. A megvalósítás során felhasználjuk azt az ismétlődő logikát, hogy a mezők és a hozzájuk tartozó labelek ugyanolyan struktúrában követik egymást.

A két fájl:

custom_locator_teszt.robot

custom_locator_keyword.robot

A működés

Futtatjuk a custom_locator_teszt.robot fájlt. Suite setupban meghívásra kerül az egyedi lokátor stratégia beállítása. Ebben a kulcsszóban „regisztráljuk” a lokátorunkat. Jelen esetben label néven.

A teszteset lépéseiben „label=” kifejezéssel hivatkozunk rá. Ilyenkor lefut a label alapú azonosítás kulcsszó, melyben a locator paraméter megkapja az adott szót, (pl.: Name), majd a logikánkat tartalmazó xpath-ba behelyettesítődik a paraméter és visszaadja a hozzá tartozó elemet.

Az xpath megalkotásánál az a logika lett követve, hogy a szöveget tartalmazó td elemet mindig egy olyan td elem követi, amiben lapul vagy egy input vagy egy textarea elem.(így van összekötve a label és a hozzá tartozó objektum)

Ez persze a gombra nem volt igaz. Ott természetesen ugyanúgy használható volt egy sima xpath.

Levezetésképp…

Ez tipikusan olyan funkció, ami nélkül lehet élni, de ha valaki könnyíteni szeretné a munkáját, akkor nagyon hasznos tud lenni. Használjátok egészséggel! 🙂

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

Hogyan csökkenti a Blind CV a felvételi kockázatot?

A sorozatunk előző részeiben megvizsgáltuk a Blind CV (anonim önéletrajz) módszertan gyakorlati működését (Blind CV a tesztelői staffingban), és beszéltünk a staffing sebességéről. Most azonban egy lépéssel hátrébb lépünk, és a projektmenedzsment egyik legkritikusabb területére fókuszálunk: a kockázatkezelésre. Bármely IT vezető megerősítheti: a szoftverfejlesztés egyik legnagyobb kockázata nem a technológia, hanem az emberi tényező. A rossz

Blind CV a tesztelői staffingban – miért működik?

Bevezetés Az előző cikkünkben (Gyors tesztelői kapacitásbővítés) már érintettük azt a „pánikhelyzetet”, amikor a projektnek tegnapra kellene ember. Ilyenkor a kapkodás a legnagyobb ellenség, és gyakran pont a hagyományos, lassú kiválasztási folyamatok állnak a gyors tűzoltás útjába. Itt jön a képbe a Blind CV (anonim önéletrajz), amiről korábban már írtunk a kockázatcsökkentés kapcsán (Blind CV a

Gyors tesztelői kapacitásbővítés (QA Staffing) – 5 tipikus hiba, amivel elégeted a büdzsét

Bevezetés A projekt késésben van. A határidő vészesen közeleg. A menedzsment ideges. Mi az első reflex? „Fel kell vennünk még embert! Tegnapra!” Ismerős a helyzet? Valószínűleg mindenki találkozott már vele, aki dolgozott IT projektben. A pánikgomb megnyomása ilyenkor természetes reakció. Az extra erőforrás bevonása valóban életmentő lehet, de csak akkor, ha okosan csináljuk. A kapkodó, előkészítetlen

Scroll to Top