2011. szeptember 15., csütörtök

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 basedloginForm:userNameId
Name AttributeloginForm:userName
CSS basedcss=#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!

Nincsenek megjegyzések:

Megjegyzés küldése