Website testen
-
Für solche Fragen ist ein Selenium Fachforum wohl besser geeignet.
Ich kann mir nämlich nicht vorstellen dass das die beste Lösung ist.Ich selber schreibe keine Selenium Tests, deshalb kenne ich die Tricks auch nicht. Aber prinzipiell funktioniert Selenium sehr gut - solche trivialitäten sind sicher schon per Standardlösungen abgedeckt.
-
Shade Of Mine schrieb:
Für solche Fragen ist ein Selenium Fachforum wohl besser geeignet.
Ich kann mir nämlich nicht vorstellen dass das die beste Lösung ist.Ich selber schreibe keine Selenium Tests, deshalb kenne ich die Tricks auch nicht. Aber prinzipiell funktioniert Selenium sehr gut - solche trivialitäten sind sicher schon per Standardlösungen abgedeckt.
Eher nicht, fürchte ich.
Es gibt implicit waits, die beziehen sich aber - nach meinem Verständnis - nicht auf dieses Szenario.
Dann gibt es anscheinend auch eine automatische Prüfung von documument.ready-state. Wenn ich zum Beispiel einen Button klicke, der die Website neu lädt, dann erkennt Selenium das und wartet mit der nächsten Aktion, bis alles fertig geladen hat. Ohne, dass ich irgenwas dafür tun muss.Sofern ich gelesen habe schreibt man Selenium-Tests wohl so, wie ich gemeint habe.
Aber Du hast Recht, das Selenium-Forum wäre jetzt wohl der deutlich bessere Ort, um sowas zu klären.
Danke trotzdem noch mal an alle Beteiligten!
-
Wir verwenden dafür "waitForElementPresent" hab ich mir sagen lassen. HTH.
-
Shade Of Mine schrieb:
Wir verwenden dafür "waitForElementPresent" hab ich mir sagen lassen. HTH.
Das ist in RC das Aquivalent zu ImplicitWaits oder eben ExplicitWaits.
ImplicitWaits greifen hier leider nicht.
Daher müsste man an der Stelle gezielt sagen: "Ich will, dass du x Sekunden wartest, falls sich dieses Element nicht anklicken lässt". Finde es schade, dass hier der ImplicitWait nicht greift. Aber wird schon seinen Sinn haben.
Ich denke man sollte sich fast eine eigene Utility-Class schreiben und nutzen. Sonst hat man immer inkonsistente Tests.
Generell scheint mir die ganze Thematik gar nicht so simpel zu sein. Man muss sehr aufmerksam und sauber programmieren, um nicht ständige fehlschlagende Tests zu haben, die eigentlich laufen sollten.
-
BitteTesten schrieb:
Ich denke man sollte sich fast eine eigene Utility-Class schreiben und nutzen. Sonst hat man immer inkonsistente Tests.
Generell scheint mir die ganze Thematik gar nicht so simpel zu sein. Man muss sehr aufmerksam und sauber programmieren, um nicht ständige fehlschlagende Tests zu haben, die eigentlich laufen sollten.
Ja, man sollte schon einen Wrapper schreiben und wenn möglich in den Tests selbst keine reinen Selenium Funktionen verwenden.
Das macht erstens den eigentlichen test übersichtlicher und zweitens muss man nicht jeden einzelnen Test anpassen, wenn sich was an der Seite ändert, sondern nur die entsprechende Funktion.Die Pflege der Tests bzw. des 'WrapperKits' kann dann aber trotzdem noch aufwändig sein, sofern sich die Webseite selber noch in der Entwicklung befindet und ständig verändert wird...
-
Klingt sinnvoll, ja.
Soweit würde ich eigentlich denken:
- Page Object Models für jede Seite
- Eine overall utility-class, die kritische Selenium-API Funktionen wie .click() wrapt und zumindestens eine gewisse Zeit an Fehler toleriertAber ... mit dem Page Object Model weiß ich nicht genau, wie ich Prozesse angehen soll, die über mehrere Seiten operieren.
Da müsste ich in dem Text uebergreifenderProzessXY dann Page Object Models von mehreren Seiten verwenden. Das fände ich irgendwie komisch.Ich denke fast an Process Object Models, irgendwie. Zumal auch nicht jeder Prozess immer alles von einer Page braucht, daher fände ich es viel logischer, sich an den Prozessen zu orientieren und abgängig von diesen solche Models zu schreiben.
Was meint Ihr dazu?