Selenium - Lokátor stratégia kiválasztása

Az előző bejegyzésemben a Selenium IDE parancsairól írtam, azonban arról még nem esett szó hogy a felvett parancsok hogyan is mutatnak rá a html elemekre. A mostani bejegyzésem tehát a Selenium lokátorokról fog szólni, kiemelve a JSF-es alkalmazások lokátor stratégia választását.

A Selenium lokátorok lehetővé teszik, hogy kiválasszuk azt a html elemet amelyre a Selenium parancsot végre akarjuk hajtani. A parancshoz tartozó lokátor a Selenium IDE target mezőjében jelenik meg. A html elemek kijelölésére többféle lokátor stratégia közül is választhatunk, melyeket lokátorTípus=lokátor formában tudunk megadni, bár a lokátor típus megadása nem minden esetben kötelező. Az alábbi táblázat a fontosabb lokátor stratégiákat szemlélteti egy-egy példán keresztül:

Lokátor stratégia	Példa
Identifier based	loginForm:userNameId
Name Attribute	loginForm:userName
CSS based	css=#usernameInputStyle
DOM Index	document.forms[0].elements[1]
XPath Attribute	//input[@id='loginForm:userNameId']
XPath Id Relative	//div[@id='userNameId_inputTextOuterDiv']/input
XPath Position	//div/input

A Selenium IDE Locator Assistance funkciója lehetőséget ad arra, hogy a rögzített parancsokhoz tartozó alapértelmezésként felvett lokátort egy másikra módosítsuk. Ez a feature pedig pont jól fog jönni a JSF alapú alkalmazások Selenium teszteléséhez. A Locator Assistance funkciót a Selenium IDE target combobox lenyitásával érhetjük el. A target mezőnél akár saját kifejezést is megadhatunk, de arra figyeljünk, hogyha a lokátor több html elemre is illeszkedne az oldalon, akkor a legelsőnek megtalált elem kerül kiválasztásra.

Lokátor stratégia kiválasztása JSF alapú alkalmazásokhoz

Általános esetben az azonosító alapú lokátor stratégia használata javasolt, mivel a html elem azonosítója mindig egyértelműen beazonosítja az elemet, így az oldal későbbi átstrukturálása esetén is ugyanarra az elemre fog mutatni, továbbá a html elem megtalálása szempontjából is az azonosító alapú stratégia tekinthető a leggyorsabbnak hasonlóan a name attribútum alapú lokátor stratégiához.

JSF-es alkalmazások esetén sajnos ez nem teljesen igaz, mivel a gyerek elemek azonosító képzésénél a szülő elemek azonosítói is szerepet játszanak. Nézzük az alábbi példát, ahol is egy JSF/RichFaces-es kódrészlet és az ebből kirenderelt html kód látható:

A html kimenet input azonosítóinak és name attribútumainak generálásában a szülő form azonosítója is részt vesz, így ha nem adunk meg azonosítót, az id a html kimenetnél nem fog szerepelni, valamint a name attribútum esetében kiegészül egy generált j_id32 értékkel.

A következő JSF/RichFaces ill. generált html kódrészlet egy olyan átstrukturálást szemléltet ahol is a form és az input elemek közé bekerült egy a4j:repeater elem. Ebben az esetben a generált html input azonosítói is megváltoznak, mivel az azonosítókhoz hozzáadódik egy ar:sorszám rész is az a4j:repeater azonosítójától. 

A felvázolt problémakör után lássuk, hogy milyen lokátor stratégiák közül érdemes választani a JSF-es alkalmazások Selenium-os teszteléséhez. A választás függ a környezettől, így a végső döntéskor az alábbi szempontok szerint mérlegeljünk.

1. Azonosító vagy name attribútum alapú lokátor stratégia

• A leggyorsabb lokátor stratégia.
• Használatához az azonosítókat mindig meg kell adni a JSF kódban, különben az id attribútum nem generálódik ki, a name attribútumnál pedig j_id123 formátumú azonosítók generálódnak melyekre a tesztek készítése során nem hagyatkozhatunk a változékonyságuk miatt.
• Az oldal módosítására és átstrukúrálására nem annyira érzékeny. Új elem felvétele esetén (pl.: új input felvétele a form alá) az azonosítók nem módosulnak (kivéve datatable, repeater beszúrásakor). A form-on kívül definiált elemek legtöbbször nincsenek hatással a form-on belüli azonosítókra.

2. XPath Position alapú lokátor stratégia

• Internet Explorer alatt akár jelentős lassulás is tapasztalható a tesztek futtatása során, az elemek kikeresésekor.
• Használatához az azonosítókat nem kötelező megadni, mivel ez a stratégia a html elemek sorrendiségére és elhelyezkedésére épít.
• Az oldal módosításra teljes mértékben érzékeny. Változtatás esetén szinte mindig megváltozik a html elemek sorrendisége vagy elhelyezkedése, így az elemekhez tartozó XPath kifejezések is. Ez azt jelenti, hogy a JSF kód átstruktúrálása esetén a parancsokhoz tartozó XPath lokátorokat újra fel kell venni.
• Abszolút XPath kifejezések helyett érdemes relatív XPath kifejezéseket használni.

3. XPath ID Relative lokátor stratégia

• Azonosító és XPath position alapú lokátor stratégia ötvözése.
• Használjunk relatív XPath kifejezéseket, melyeket egy fix azonosítótól kezdve adjunk meg.
• Válasszunk az elemhez képest minél közelebbi fix azonosítót és minimalizáljuk az XPath kifejezés hosszát, így a módosításokra sem lesz annyira érzékeny.

A JSF-es alkalmazások Seleniummal való tesztelésénél - beleértve a RichFaces, IceFaces, PrimeFaces-es webes keretrendszereket - tehát annyi dolgunk van, hogy az említett három stratégia közül kiválasztjuk az igényeinknek legmegfelelőbbet, majd a Selenium Locator Assistance funkciójával átállítjuk a Selenium parancsokhoz tartozó lokátor stratégiát. Mivel a Selenium IDE-ben alapértelmezett lokátor stratégia választásra nincs lehetőség, ezért egyelőre ezt manuálisan kell elvégezni esetleg módosíthatjuk a Selenium IDE kódjában a default beállítást!

A Selenium-os cikksorozatom következő részében megmutatom, hogy hogyan készíthetünk újrafelhasználható teszteket a Selenium IDE-ből kiexportálható spagetti kód helyett!