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

Nincs elég tesztelő? Ez az 5 fájdalmas következmény a projektre

Bevezető „Spóroljunk a tesztelésen, majd a fejlesztők megnézik egymás kódját.” Hányszor hallottuk már ezt a mondatot projektindító megbeszéléseken? Logikusnak tűnhet: a fejlesztő ért a legjobban a kódhoz, miért fizetnénk külön embert arra, hogy „kattintgasson”? Ez a gondolkodásmód azonban olyan, mintha a könyvelőt kérnénk meg, hogy auditálja a saját mérlegét. Papíron minden rendben lesz, de a

Miért nem skálázódik QA nélkül egy IT projekt?

Bevezető A szoftverfejlesztés világában létezik egy visszatérő, fájdalmas forgatókönyv, amit szinte minden startup alapító és technológiai vezető átél legalább egyszer. Ez a történet mindig ugyanúgy kezdődik: eufóriával. A projekt elején minden olajozottan működik. A csapat kicsi, agilis, és mindenki mindent tud a rendszerről. A fejlesztők reggel megírják a kódot, délben tesztelik a saját gépükön, délután

QA staffing: hogyan lehet gyorsan és biztonságosan kapacitást bővíteni?

Bevezetés Előző cikkünkben (itt olvasható) arról írtunk, hogy mikor érdemes külsős tesztelőt bevonni, és mikor intő jel, ha csak tűzoltásra használnánk őket. Most, hogy már tudjuk a „mikor”-t, evezzünk gyakorlatiasabb vizekre, és nézzük meg a „hogyan”-t. Hogyan lehet úgy bővíteni a csapatot, hogy az ne a káoszt növelje, hanem a megoldást hozza el? (Megjegyzés: A szakmában gyakran

Scroll to Top
Passed
Adatvédelmi áttekintés

Ez a weboldal sütiket használ, hogy a lehető legjobb felhasználói élményt nyújthassuk. A cookie-k információit tárolja a böngészőjében, és olyan funkciókat lát el, mint a felismerés, amikor visszatér a weboldalunkra, és segítjük a csapatunkat abban, hogy megértsék, hogy a weboldal mely részei érdekesek és hasznosak. Adatkezelési tájékoztató