Was macht einen guten selenium locator aus?

Bei der Automatisierung von UI-Tests mit Selenium ist es oft nicht ganz klar, welche Methode und welcher Locator zum Auffinden eines Elements verwendet werden soll. Einige Locators sind weniger zuverlässig und weniger gut lesbar als andere. Und in der Regel gibt es eine Vielzahl von Optionen, um zu einem gewünschten Element zu gelangen.

Um genau zu sein, hier sind einige Dinge, die wir (mit ESLint) in unserem UI-Testautomatisierungsprojekt (mit Protractor zum Testen einer AngularJS-Anwendung) durchgesetzt haben:

keine Bootstrap-Klassen innerhalb von CSS-Selektoren (die Idee ist, so wenig UI/Layout-spezifische Dinge wie möglich zum Auffinden von Elementen zu verwenden)
keine internen Angular-Klassen in CSS-Selektoren - Dinge wie ng-scope oder ng-binding sind rein technisch und sollten nicht in Locatoren verwendet werden
Verwendet "xpath" nur, wenn es absolut notwendig ist (was in diesem Styleguide empfohlen wird).

Die Frage:

Welche anderen Empfehlungen gibt es für die Lokalisierung von Elementen in Selenium?

Gute Frage, vor allem, wenn die Leute es lesen und aufhören, XPath zu verwenden.

• Selenium Best Practices nennt die Reihenfolge: id > name > css > xpath
• Mozilla erklärt, warum IDs
• Saucelabs erklärt, warum CSS-Locators gegenüber XPath bevorzugt werden
• slideshare vergleicht Locators (Folie 23: CSS vs XPath)
• CSS vs. XPath - mit Benchmark
• Simon Stewart mit Video

Ich habe irgendwo gelesen (kann den Link nicht finden), dass eine weitere Ursache für fehlerhafte Tests das Auffinden von Elementen über veränderbare Attribute ist. Das Problem ist, dass sowohl der Browser als auch Selenium einen internen Cache verwenden, um den Zugriff auf die Attribute zu beschleunigen, so dass die Zerschlagung dieses Caches möglicherweise nicht synchron ist und zu fehlerhaften Tests führt.

• CSS vs. XPath: Der Benchmark sagt, dass der Unterschied bei aktuellen Browsern (die Seite hat leider kein Datum) minimal ist. Da die Seiten jedoch mit CSS gestaltet werden, kann man davon ausgehen, dass CSS stabiler ist als XPath. Enthält einige Links für weiterführende Überlegungen.
  Ausnahme, bei der XPath OK ist: übergeordnetes Element des aktuellen Elements (wenn ein übergeordnetes Element keine ID oder keinen Namen hat).

Meine bevorzugte Reihenfolge für das Auffinden von Elementen ist:

By.ID > By.NAME > By.CSS_SELECTOR > By.LINK_TEXT > By.CLASS_NAME > By.TAG_NAME > By.XPATH

Die Wahl eines guten Locators ist sehr wichtig - sie bestimmt, wie zuverlässig, lesbar, wartbar und dauerhaft Ihre Tests sein werden; wie sehr sie von der Benutzeroberfläche und Designänderungen abhängig sein werden. Denken Sie daran: Die Wartung von End-to-End-Tests ist im Allgemeinen schwierig und teuer (gute Lektüre zu diesem Thema).

Hier ist eine Reihe von Dingen, über die Sie bei der Auswahl eines Locators nachdenken sollten:

• Umfang. Bevorzugen Sie "datenorientierte" Elemente und Attribute gegenüber "layoutorientierten". Mit anderen Worten: Versuchen Sie, nicht von der Wahl des Seitendesigns abhängig zu sein. Sie wollen im Allgemeinen nicht, dass eine nahtlose Designänderung, z. B. bei der Größe eines Containers, Ihren Locator zerstört:
  • schlechter:

    .col-md-1.col-xs-6 input

  • besser:

    .content input.email-input

     

Sagt "Nein" zu XPaths. XPath ist die langsamste Ortungstechnik; XPath-Ausdrücke sind im Allgemeinen schwieriger zu pflegen und zu debuggen (Referenz). Und wenn es um mehrwertige Attribute wie class geht, muss man eine zusätzliche Verkettung vornehmen, um zuverlässig eine Klasse aus mehreren Klassenwerten zu finden, was die Komplexität erhöht und die Lesbarkeit verringert:

• schlechter:

  //*[enthält(@class, 'some-class')//input[@type='text']

• besser:

  .some-class input.email-input

   

Technologie. Versucht, nicht von der zugrunde liegenden Technologie der UI-Implementierung abhängig zu sein. Im Falle von AngularJS sollten Sie beispielsweise keine internen Angular-Attribute oder -Klassen wie ng-scope oder ng-binding verwenden.

• schlechter:

  .ng-scope.ng-binding
  
  
  

• besser:

  .email-input

   

HTML-Struktur. Versuchen Sie, so wenig wie möglich von der HTML-Struktur der Seite abhängig zu sein. Je mehr Elemente Sie auf dem Weg zum gewünschten Element haben, desto höher ist die Wahrscheinlichkeit, dass eine UI-Änderung Ihren Locator plötzlich zerstört:

• schlechter:

  .content > table > tbody > tr:nth-child(2) > td.cell > input#email

  besser:

  .content input#email

  IDs sind sicher und schnell. Die Suche nach Elementen anhand von IDs läuft darauf hinaus, dass die Browser die Methode document.getElementById() verwenden, die auf Geschwindigkeit optimiert ist. Und obwohl es keine Beschränkungen für doppelte ID-Werte auf einer Seite gibt, werden sie in der Regel als eindeutig angenommen und gestaltet.

• schlechter:

by.css(".content > .main-container > form.login input[type=password]")

• besser:

by.id("passwort")

Einige andere verwandte Themen:

Ist das Hinzufügen von IDs zu allem Standard bei der Verwendung von Selenium?
Was ist der beste und schnellste Weg, um das Element mit Webdriver zu finden? By.XPath oder By.ID oder etwas anderes? Und warum?

• Ist das Hinzufügen von IDs zu allem Standardpraxis bei der Verwendung von Selenium?
• Was ist der beste und schnellste Weg, um das Element mit Webdriver zu finden? By.XPath oder By.ID oder etwas anderes? Und warum?

Was macht einen guten Selenium-Locator aus?

• Lesbarkeit: Kürzer ist besser, am besten mit einem eindeutigen Namen/einer eindeutigen ID, der/die dieses einzigartige Element auf der Seite beschreibt. Fühlt euchfrei, den Code wie Klassen/Namen/id's zu ändern, um den Locator und den Test-Code sehr verständlich und lesbar zu machen.
  Wartbarkeit: Die Struktur des Locators sollte so einmalig gut sein, dass er nicht aktualisiert werden muss, wenn sich die Position des Elements auf der Seite ändert. Sofern sich die Funktionalität nicht drastisch ändert, sollten Sie in der Lage sein, die Aktualisierung von Locatoren und/oder Tests auf ein Minimum zu beschränken.

Im Wesentlichen sollte ein Locator so geschrieben und gelesen werden, als ob der Tester und der Programmierer sich wirklich darum gekümmert hätten. Sauberer Code ist auch für die Seitenstruktur und die Tests wichtig.

Welche anderen Empfehlungen gibt es für die Lokalisierung von Elementen in Selenium?

Zentralisiert die Locators in eurem Testcode, haltet ihn in DRY. PageObjects können helfen.
Arbeitet mit den Entwicklern zusammen, um gute Locators zu erstellen! Ändert euren Prozess so, dass dies möglich ist. Ein guter Tipp ist es, gemeinsam mit den Entwicklern an den Tests zu programmieren, wenn ihr eine separate QA-Person seid- Ihr könnt beide etwas lernen.