Website testen

Sofern ich jetzt gelesen habe besteht Selenium ja aus mehreren Anwendungen.

Bietet es sich an, zunächst ein paar simple Tests mit der "IDE" zusammen zu bauen und dann eben zum Beispiel in einen Webdriver Test zu übersetzen und dort auszubauen oder sollte man einfach direkt mit WebDriver loslegen?

Tobiking2

BitteTesten schrieb:

@Tobiking2 GIbt es denn da noch einen Unterschied, zu den Unit-Tests, die Backend-seitig sowieso schon bestehen? Jede Klasse im Backend hat meistens einen eigenen Unit-Test dazu, der auch schon beim Jenkins-Build mit berücksichtigt wird.

Ja, sie testen das Frontend.

Es kommt natürlich darauf an wie komplex die Logik in dem Frontend überhaupt ist. Wenn das Frontend hauptsächlich Daten vom Backend anzeigt, ist es meistens nicht nötig detaillierter zu testen. Wenn es aber z.B. darum geht das das Frontend die Preise der Produkte im Warenkorb selber zusammenrechnet, sollte das getestet werden (mit Gutschriften, Rabatte etc.). Wenn das Backend getestet wurde, wird es beim Kauf vermutlich den richtigen Preis verwenden, aber der Käufer wird nicht froh darüber sein das der angezeigte Preis falsch war.

@Tobiking2

Ah okay, sehr interessanter Ansatz um hier abzugrenzen. Ja bei uns ist tatsächlich so gut wie jede Logik im Backend umgesetzt. Jede wirklich relevante, sowas wie Preisberechnung zu mindestens.
(Beispielsweise: Warenkorb->Gutschein einfügen->Request an Backend, dieses sucht den Gutschein, fügt ihm der Warenkorb-Seite hinzu und kalkuliert den Preis neu, dann gibt es die gefüllte Seite (MVC) zurück).

Dennoch könnten solche Selenium-Tests aus meiner Sicht Sinn machen. Bin gerade dabei welche zu schreiben und ist schon ganz spaßig

Tobiking2

Ok, wenn das Backend sogar die Seitenfragmente zusammenbaut tut das Frontend ja wirklich nichts anderes als Eingaben übermitteln und daraufhin Teile der Seite zu ersetzen. Das braucht man nicht mit Unittests abdecken. Das empfangene Fragmente auch angezeigt werden, ergibt sich ja durch die Tests mit Selenium. Selbst das ausführliche Testen von Fehleingaben sehe ich nur als begrenzt nötig, da das Backend ja die Validierung vornimmt und die in den dort vorhandenen Unittests getestet werden sollte. 1-2 Testfälle die sicherstellen das auch Sonderzeichen etc. vernünftig ans Backend übertragen werden, sollten da reichen.

Hab mich jetzt die letzte Woche damit auseinander gesetzt und auch mal ein Test geschrieben.

Muss sagen, dass das ganze schon sehr cool ist.

Allerdings fühlt es sich noch sehr fragil an. Problem ist, dass bei der Website, die ich teste, viel JavaScript mit eingebunden ist. Überall ein bisschen.

Da kann man dann zum Beispiel in Chrome und IE von einem Dropdown ganz normal per Select.selectByValue etc. was auswählen, aber der FireFox macht Stress (Element not visible -> may not be interacted with). Weiß immer noch nicht wieso, das Element ist, rein aus dem HTML-Kontext, auf jeden Fall nicht disabled.
Hab ein Workaround dafür gefunden, aber nun jut.

Das größte Problem ist immer noch der IE. Während bei Chrome und FF jeweils 300 Testfälle alle positiv durchlaufen, schlagen bei IE um die 30 fehl. Weil irgendein Element plötzlich nicht mehr anklickbar ist.

Ich hab leider nicht mehr dazu gefunden, falls es einer zufällig weiß: Die implicit waits von Selenium ... beziehen die sich nur auf findElement(s) Aufrufe oder setzen die auch ein, wenn man zum Beispiel ein WebElement.click() ausführen will? Also greift der implicit wait auch, wenn ein Element (Noch) disabled ist?

Kann es sein, das du versuchst auf den gleichen Button nochmal zuzugreifen, nachdem du ihn gedrückt hast?
(dann kann es nämlich sein, dass das WebElement nicht mehr referenziert ist, weil z.b. die seite neu geladen wurde

Ich habe auch das Problem wenn z.b. ein 'Button' nicht als reiner (HTML) <button> dargestellt wird, sondern mittels CSS als UI element erstellt und über ein CSS flag enabled/disabled wird.
Dann ist der reine HTML <button> nicht sichbar oder nicht enabled und mittels Selenium kann man ihn dann nicht klicken.
(aber als Benutzer kann man trotzdem drauf klicken)
Könnte das ein Problem bei dir sein?

Lupo_off schrieb:

Kann es sein, das du versuchst auf den gleichen Button nochmal zuzugreifen, nachdem du ihn gedrückt hast?
(dann kann es nämlich sein, dass das WebElement nicht mehr referenziert ist, weil z.b. die seite neu geladen wurde

Ich habe auch das Problem wenn z.b. ein 'Button' nicht als reiner (HTML) <button> dargestellt wird, sondern mittels CSS als UI element erstellt und über ein CSS flag enabled/disabled wird.
Dann ist der reine HTML <button> nicht sichbar oder nicht enabled und mittels Selenium kann man ihn dann nicht klicken.
(aber als Benutzer kann man trotzdem drauf klicken)
Könnte das ein Problem bei dir sein?

Leider nicht, dann hätte ich eine schöne Erklärung des Fehlers

Scheint wohl einfach nicht gute Praxis zu sein, sowas wie "Klick dadrauf und dann klick auf den erschienen Button" zu schreiben. Das klappt zwar bei FF und Chrome in 100% aller Fälle. Bei IE aber nur in etwa 70%.
Anscheinend muss man eher sowas wie "Klick dadrauf und dann versuche für x Sekunden, den Button zu drücken, der eigentlich auftauchen sollte." schreiben. Umständlich aber ich denke es ist die beste Lösung dafür

Shade Of Mine

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!

Shade Of Mine

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.

Lupo4u2

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 toleriert

Aber ... 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?