Utiliser XPATH pour rechercher du texte contenant & nbsp;

J’utilise le navigateur XPather pour vérifier mes expressions XPATH sur une page HTML.

Mon objective final est d’utiliser ces expressions dans Selenium pour tester mes interfaces utilisateur.

J’ai un fichier HTML avec un contenu similaire à celui-ci:

 
    abc 
    & nbsp; 
 

Je veux sélectionner un nœud avec un texte contenant la chaîne ”   “.

Avec une chaîne normale comme “abc”, il n’y a pas de problème. J’utilise un XPATH similaire à //td[text()="abc"] .

Lorsque j’essaie avec un XPATH comme //td[text()=" "] il ne renvoie rien. Existe-t-il une règle spéciale concernant les textes avec ” & “?

Il semble que OpenQA , les gars derrière Selenium, ont déjà résolu ce problème. Ils ont défini des variables pour correspondre explicitement aux espaces blancs. Dans mon cas, je dois utiliser un XPATH similaire à //td[text()="${nbsp}"] .

J’ai reproduit ici le texte d’OpenQA concernant ce problème (trouvé ici ):

HTML normalise automatiquement les espaces dans les éléments, en ignorant les espaces de début et de fin et en convertissant des espaces, des tabulations et des nouvelles lignes supplémentaires en un seul espace. Lorsque Selenium lit le texte à l’extérieur de la page, il tente de dupliquer ce comportement. Vous pouvez donc ignorer tous les tabs et nouvelles lignes de votre code HTML et effectuer des assertions en fonction du rendu du texte dans le navigateur. Nous faisons cela en remplaçant tous les espaces blancs non visibles (y compris les espaces insécables ”   “) par un seul espace. Toutes les nouvelles lignes visibles (
,

et


nouvelles lignes formatées) doivent être conservées.

Nous utilisons la même logique de normalisation sur le texte des tables de cas de test HTML Selenese. Cela a un certain nombre d'avantages. Tout d'abord, vous n'avez pas besoin de regarder la source HTML de la page pour déterminer quelles devraient être vos assertions; "   " les symboles sont invisibles pour l'utilisateur final et vous ne devriez donc pas avoir à vous en soucier lors de l'écriture des tests Selenese. (Vous n'avez pas besoin de placer des marqueurs "   " dans votre scénario de test sur assertText sur un champ contenant "   ".) Vous pouvez également placer des lignes et des espaces supplémentaires dans vos balises Selenese

; Comme nous utilisons la même logique de normalisation sur le scénario de test que sur le texte, nous pouvons nous assurer que les assertions et le texte extrait correspondent exactement.

Cela crée un problème dans les rares cas où vous souhaitez / avez besoin d'insérer des espaces supplémentaires dans votre scénario de test. Par exemple, vous devrez peut-être taper du texte dans un champ comme ceci: " foo ". Mais si vous écrivez simplement

foo

dans votre scénario de test Selenese, nous remplacerons vos espaces supplémentaires par un seul espace.

Ce problème a une solution de contournement simple. Nous avons défini une variable dans Selenese, ${space} , dont la valeur est un espace unique. Vous pouvez utiliser ${space} pour insérer un espace qui ne sera pas automatiquement coupé, comme ceci:

foo${space}${space}${space}

. Nous avons également inclus une variable ${nbsp} , que vous pouvez utiliser pour insérer un espace insécable.

Notez que les XPath ne normalisent pas les espaces comme nous le faisons. Si vous avez besoin d'écrire un XPath comme //div[text()="hello world"] mais que le HTML du lien est vraiment " hello world ", vous devrez insérer un vrai "   " dans votre Selenese cas de test pour le faire correspondre, comme ceci: //div[text()="hello${nbsp}world"] .

J’ai trouvé que je pouvais faire la correspondance lorsque je saisis un espace non codé en dur (U + 00A0) en tapant Alt + 0160 sous Windows entre les deux guillemets …

 //table[@id='TableID']//td[text()=' '] 

travaillé pour moi avec le char spécial.

D’après ce que j’ai compris, la norme XPath 1.0 ne gère pas les caractères Unicode qui s’échappent. Il semble y avoir des fonctions pour cela dans XPath 2.0, mais il semble que Firefox ne le supporte pas (ou j’ai mal compris). Donc, vous avez à faire avec la page de codes locale. Moche, je sais.

En fait, il semble que le standard repose sur le langage de programmation utilisant XPath pour fournir la séquence d’échappement Unicode correcte … Donc, d’une certaine manière, j’ai fait la bonne chose.

Essayez d’utiliser l’entité décimale   au lieu de l’entité nommée. Si cela ne fonctionne pas, vous devriez pouvoir utiliser simplement le caractère unicode pour un espace insécable au lieu de   entité.

(Note: je n’ai pas essayé ceci dans XPather, mais je l’ai essayé dans Oxygen.)

Je ne peux pas obtenir de correspondance avec Xpather, mais ce qui suit a fonctionné pour moi avec les fichiers XML et XSL simples dans le Bloc-notes XML de Microsoft:

  

La valeur renvoyée est 1, ce qui correspond à la valeur correcte dans mon scénario de test.

Cependant, je devais déclarer nbsp en tant qu’entité dans mon XML et mon XSL en utilisant ce qui suit:

 < !DOCTYPE xsl:stylesheet [  ]> 

Je ne sais pas si cela vous aide, mais j’ai pu trouver nbsp en utilisant une expression XPath.

Edit: mon exemple de code contient les caractères ‘& nbsp;’ mais la surbrillance de la syntaxe JavaScript le convertit en caractère espace. Ne vous trompez pas!

Gardez à l’esprit qu’un processeur XML conforme aux normes aura remplacé toutes les références d’entité autres que les cinq normes XML standard ( & > < > < " ) par le caractère correspondant dans l’encodage cible au moment où XPath les expressions sont évaluées. Étant donné ce comportement, les suggestions de PhiLho et de jsulak sont la voie à suivre si vous souhaitez utiliser des outils XML. Lorsque vous entrez   dans l’expression XPath, elle doit être convertie dans la séquence d’octets correspondante avant que l’expression XPath ne soit appliquée.

Rechercher   ou seulement nbsp – l’avez-vous essayé?