Blog

Alle Beiträge mit dem Tag Selenium

Besser testen mit Thucydides

Veröffentlicht von Holisticon AG am 09.09.14.
Kategorie: Software-Architektur - Keine Kommentare

Wer kennt das nicht: Oberflächen-Tests werden in vielen Projekte stiefmütterlich behandelt. Wenn überhaupt automatisierte Oberflächen-Tests existieren, sind sie meist schwer zu pflegen oder nicht wirklich stabil. Gerade vor dem Hintergrund von Continous Integration (CI) und Test Driven Development (TDD) ist das eigentlich ein unhaltbarer Zustand. Gerade Oberflächen-Tests sind extrem wertvoll, um kritischen Pfade abzutasten, z.B. als Smoke-Test vor einem Live-Deployment. Mit Thucydides ist es möglich, Oberflächen-Tests lesbarer, wartbarer und wiederwendbar umzusetzen. Dabei wird das Page-Object-Pattern umgesetzt, um diese Anforderung umzusetzen.
weiterlesen

Selenium und Proxyauthentifizierung

Veröffentlicht von Holisticon AG am 23.11.11.
Kategorie: Technologie - Keine Kommentare


In einem unserer Projekte haben wir eine Webanwendung erstellt, für die wir einen automatischen Integrationstest brauchten. Diese Webanwendung ist allerdings nur von bestimmten IP-Adressen zu erreichen, weshalb der Test seine Http-Requests durch einen Proxy leiten muss, der eine Authentifizierung erfordert. Eigentlich ein alltägliches Szenario: Schließlich soll nicht jeder Zugriff auf eine Applikation haben, bevor der Zeitpunkt des Livegangs gekommen ist.
weiterlesen

Testdrive your WebApplication with Selenium WebDriver and PageObjects (Teil 1)

Veröffentlicht von Holisticon AG am 09.05.11.
Kategorie: Technologie - Keine Kommentare

Sucht man nach Möglichkeiten zum Testen von Webanwendungen, landet man relativ schnell bei Selenium, einem Framework, das vielen Anwendungsentwicklern bekannt sein dürfte. Hierbei werden Tests klassisch via capture & replay aufgezeichnet und wieder zum Ablauf gebracht. Dazu kann z.B. im Firefox das Selenium-IDE-Plugin verwendet werden. Die aufgezeichneten Tests werden standardmässig im HTML-Format gespeichert, können jedoch auch direkt in JUnit-Tests exportiert werden.

Da bei dieser Variante kaum mehr eigenhändiges Codieren der Tests notwendig ist, eignet sich dieses Verfahren für Szenarios, bei denen Tester nicht programmieren können oder sollen. Erfahrungsgemäß bleibt der Einstieg in den Code aber auch bei diesem Szenario nicht erspart, denn mitunter müssen noch wait() statements eingebaut werden, weil die Antwortszeiten zwischen den Rechnern der Tester und der Integrationsumgebung doch stark abweichen können.
weiterlesen