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:
//*
- 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")
- 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.
https://www.dev-crowd.com/2022/05/23/coding-guidelines-fuer-test-engineere/
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.
Read the full article