Dans notre automatisation actuelle (utilisant SELENIUM / webDriver / Java), nous utilisons par définition, Récemment, nos devs frontaux ont proposé de mettre en place une nouvelle classe d'attributs qui commence par "test =". Je pense que c'est une bonne idée puisque nous pourrions trouver des webelements en cherchant simplement ce texte de texte, plutôt que les valeurs que @Findby très largement. Par exemple: @Findby peut localiser un sélecteur à l'aide des éléments suivants: Utilisation, ID, Nom, Nom de classe, CSS, TAGName, LinkeText, PartialLinkText et XPath. @Findby utilise intrinsèquement. Ma question est la suivante, serait-il préférable de étendre la fonctionnalité existante de @Findby ou, crée une nouvelle façon de rechercher les Webéléments que nous utilisons dans nos tests?
3 Réponses :
Si je vous ai bien compris, vous pouvez continuer à utiliser @Findby Annotation avec des sélecteurs CSS tels que CSS = "[Test = '...']".
Oui, je savais ça. Ma question spécifique est de savoir s'il est préférable d'étendre la Findby ou de créer une nouvelle classe capable de rechercher des attributs / éléments qui ne suivent pas les conventions de Findby actuelles.
Tout d'abord, il n'y a pas de "meilleures pratiques", juste ceux qui fonctionnent bien dans votre contexte particulier. Désolé, c'est une vieille grièette de la mienne ...
Je ne passerais pas l'effort d'attributs personnalisés à moins que vous ne puissiez pas travailler avec une approche existante. Je préfère utiliser les localisateurs existants (trouvez la logique) dans la mesure du possible.
Dans la mesure du possible, utilisez les attributs d'identification. Si la page est valide HTML, les identifiants sont uniques sur la page. Ils sont extrêmement rapides pour la résolution dans chaque navigateur et que l'interface utilisateur peut changer de manière spectaculaire, mais votre script localisera toujours l'élément.
Parfois, les identifiants ne sont pas le bon choix. Les identifiants générés dynamiquement sont presque toujours le choix mal lorsque vous travaillez avec quelque chose comme un contrôle de la grille. Vous comptez sur une pièce d'identité qui est probablement liée à la position de la rangée spécifique, puis vous êtes vissé si votre ligne change.
Dans certains de ces cas, votre DevS peut vous aider en ajoutant des valeurs constantes en ajoutant ou en préparé à une valeur d'identification générée dynamiquement. ASP.NET WebForms fait des choses folles avec des valeurs générées dynamiquement, j'ai donc utilisé un suffixe à mon avantage plusieurs fois.
Le texte de la liaison, les valeurs d'attribut de nom et les sélecteurs CSS (style JQuery) sont d'excellents seconde choix lorsque vous ne pouvez pas obtenir d'une carte d'identité stable, fiable ou de non pas disponible.
XPath est mon dernier choix dans presque toutes les situations. C'est lent, peut être extrêmement fragile et est difficile à gérer quand c'est un XPath complexe. Cela dit, si vous devez monter et descendre la page DOM pour vos localisateurs, c'est le seul choix.
Utiliser l'une des méthodes de Findby existantes signifie que vous utiliserez une stratégie de localisation bien comprise et bien prise en charge. C'est un gros bonus lorsque vous essayez de trouver un ancien test, ou lorsque vous faites une nouvelle personne à votre équipe.
C'est mon 0,02 $.
Bien dit, Jim. C'est ma réponse.
Je pense que cela aidera Les meilleures pratiques de localisateurs de sélénium
localisateurs les plus savoureux:
identifiant
Nom
Classer
Relier
Texte ou texte partiel
Essayez ceci Lien ou simplement Google Query "Meilleures pratiques pour les localisateurs en ratière et en sélénium - le localisateur de la vie"