Wie kann ich meine Selenium-Tests weniger spröde machen?

Question

Wir verwenden Selenium, um die UI-Schicht unserer ASP.NET-Anwendung zu testen. Viele der Testfälle testen längere Abläufe, die sich über mehrere Seiten erstrecken.

Ich habe festgestellt, dass die Tests sehr fragil sind, nicht nur durch Code-Änderungen, die tatsächlich die Seiten ändern, sondern auch durch harmlose Refactorings wie die Umbenennung eines Steuerelements (da ich die ClientID des Steuerelements an die Klickmethode von Selenium übergeben muss, usw.) oder den Austausch eines GridViews durch einen Repeater. Als Ergebnis finde ich mich 'verschwende' Zeit damit, Zeichenfolgenwerte in meinen Testfällen zu aktualisieren, um defekte Tests zu beheben.

Gibt es einen Weg, um wartbarere Selenium-Tests zu schreiben? Oder ein besseres Web-UI-Testwerkzeug?

Bearbeitet, um hinzuzufügen: Normalerweise wird der erste Entwurf erstellt, indem ein Test im IDE aufgezeichnet wird. (Dieser erste Schritt kann vom QA-Personal durchgeführt werden.) Dann refaktoriere ich den generierten C#-Code (Extrahiere Konstanten, extrahiere Methoden für wiederholten Code, wiederhole möglicherweise den Testfall mit unterschiedlichen Daten, usw.). Aber der allgemeine Codefluss für jeden Testfall bleibt ziemlich nahe am ursprünglich generierten Code.

Answer 1

Ich habe festgestellt, dass die Verwendung von XPath-Ausdrücken in Selenuium-RC viel zur Robustheit eines Tests beiträgt.

Ich schreibe meine Tests auf ähnliche Weise. Der erste Durchgang wird oft über das IDE/Record geschrieben, um den Großteil meines Seitenflusses und Klickoperationen zu erhalten. Sobald ich das habe, gehe ich Schritt für Schritt durch den Test über Selenium-RC und füge Assertions hinzu sowie ändere absolute Widget-Locator in lesbarere und benutzerfreundlichere XPath-Ausdrücke (und dokumentiere den Test! :))

Etwas, worauf man achten sollte.. Wenn Ihre Tests viel XPath enthalten, können sie in IE6 möglicherweise etwas langsamer ausführen aufgrund seiner schlechten Javascript-Ausführungsfähigkeiten. (Ich habe einige Testsuites, die unter IE fast eine Stunde länger dauern als unter FF. Es ist machbar, aber etwas, woran man denken sollte, wenn man die Tests schreibt.)

Answer 2

Selenium hat in der Theorie eine Abstraktion namens UI Element (die Dokumentation finden Sie hier).

Die Funktionen wären

• abstrakte Lokatoren, unabhängig von der konkreten HTML-Implementierung; dies würde gut zum Konzept eines Komponente oder Widgets eines Web-Frameworks passen,

• Rollup-Regeln, die es ermöglichen, mehrere Befehle in einen einzigen abstrakten Befehl zu fusionieren.

Ich habe ein paar Tage damit gekämpft, diese Funktion zu nutzen, aber am Ende habe ich beschlossen, sie aufzugeben, aus folgenden Gründen:

• einige Konzepte, wie z. B. Offset-Lokatoren (denken Sie an sie als Teile einer Komponente), sind nicht vollständig oder nützlich entwickelt;
• das Feature wird von den Formatters nicht vollständig unterstützt und je neuer der Formatter ist, desto weniger wird das Feature unterstützt, was darauf hindeutet, dass die Kernentwicklung von Selenium dieses Feature hinter sich lässt;
• es ist nicht vollständig in Selenium 2.0 (WebDriver) integriert.

Answer 3

Ich denke, dass Xpath der beste Weg ist, um robuste Selenium-Tests zu gewährleisten. Aktuell arbeite ich an einer Bibliothek, die dabei hilft, XPath-Ausdrücke einfacher zu schreiben.

Bei Interesse kannst du es hier überprüfen: http://www.unit-testing.net/CurrentArticle/How-To-Write-XPath-for-Selenium-Tests.html