Perché uno dovrebbe preferire usare CSS su XPath in IE?

Sto lavorando a un’applicazione compatibile solo con IE7 e IE8. Non sapevo perché, ma alcuni hanno suggerito di usare CSS su XPath identificando gli elementi in IE. Quando ho visitato il sito ufficiale del Selenium. Ho letto il messaggio

WebDriver utilizza le funzionalità XPath native del browser, laddove ansible. Su quei browser che non hanno supporto nativo per XPath, abbiamo fornito la nostra implementazione. Questo può portare ad un comportamento inaspettato a meno che non si sia consapevoli delle differenze nei vari motori xpath.

Mi piacerebbe sapere dove posso trovare le differenze nei vari motori xpath e in quali situazioni dovrei usare CSS e in cui XPath in particolare se sto usando IE. Grazie.

Secondo il rapporto di Ashley Wilson dai laboratori di salsa :

Pro :

  1. Sono più veloci
  2. Sono più leggibili
  3. Il CSS è la strategia di localizzazione di jQuery
  4. Nessun altro usa XPATH comunque!

È un po ‘obsoleto, tuttavia qui ci sono i numeri:

immagine dal sito Web del laboratorio di causa

Personalmente, vorrei discutere su (2) -e dichiarazione, devo essere d’accordo con il resto.

Contro :

  1. Nessuna navigazione “dal basso verso l’alto”. XPath ha elem\..\another_elem
  2. Sizzle è stato iniettato? Oppure viene utilizzato il parser del localizzatore CSS del browser? Dipende dal browser e ci sono incoerenze.

Il motivo principale per suggerire i selettori CSS su XPath in IE è la performance. IE non fornisce un’opzione nativa XPath-over-HTML come Firefox e Chrome. Tuttavia, fornisce un motore di selezione CSS nativo, che sarà sempre più veloce dell’implementazione del motore XPath JavaScript-only utilizzato nel driver IE. E il confronto delle prestazioni non è nemmeno vicino. L’ho visto misurare più lentamente di un ordine di grandezza per i localizzatori XPath rispetto ai selettori CSS (anche se al momento non riesco a trovare la citazione). Questo è particolarmente vero nelle versioni di IE prima delle 9, dove il motore JavaScript di IE era molto più lento del motore JavaScript di Chakra introdotto in IE9 a 32 bit.

Usare il localizzatore CSS è l’opzione migliore, non solo su IE, anche su FF e Chrome. Inoltre, xpath è sempre la scelta peggiore, perché ha bisogno di analizzare l’intera pagina per trovare un elemento semplice, quindi se vuoi ottenere prestazioni nei tuoi test e puoi evitarlo, fallo e basta.

Inoltre, se stai usando pageObjects ti consiglio vivamente di usare cacheLookup, quindi l’elemento si troverà una sola volta:

 @CacheLookup @FindBy(id="doLogin") private WebElement loginButton; 

Personalmente, faccio quanto segue:

  • Se l’elemento ha class css, usa questo localizzatore
  • Se l’elemento ha il nome o l’id, usa questo localizzatore
  • Se nessuno dei precedenti è presente e non puoi usare linkText o un altro localizzatore, vai su xpath.

Brevizza e Chiarezza sono altri motivi, oltre alla velocità.

Oltre alla velocità, trovo che il css sia solitamente più breve, più pulito e più facile da leggere. Per esempio:

XPath:

  //ol[@class='choice-group'//li//label//input 

vs

css:

  css=ol.choices-group li label input