Sie setzen Selenium 1 / 2 (WebDriver) in Ihrer Umgebung ein? Falls Sie es nicht tun und kein anderes Test-Framework verwenden werden Sie früher oder später damit anfangen. Oder wie sonst stellen Sie die Qualität Ihrer Releases sicher? Natürlich kann Selenium, außer zum Testen, auch zur Automatisierten Steuerung von Browsern eingesetzt werden. Den Möglichkeiten sind hier kaum Grenzen gesetzt.

Wer Selenium (oder ein anderes, vergleichbares Test-Framework) einsetzt, wird damit schonmal die Eine oder Andere Unbequemlichkeit erlebt haben, angefangen mit "Wie integriere ich das Selenium in meinen Projekten" bis hin zum "Wie minimiere ich den Aufwand für die Pflege meiner bestehender Tests" - Stichwort: Locator. Ich gehe etwas tiefer darauf ein:

Obowohl das automatisierte Testen sehr viel Nutzen bringt, wie z.B. frühe Erkennung von Bugs, steht es an der Tagesordnung den Aufwand der Testerstellung minimal zu halten. Schließlich dient es "nur" der eigenen Qualitätsicherung und kann nicht direkt faktoriert werden. Anstatt die Tests händisch zu schreiben, kann die Selenium IDE eingesetzt werden, um die Tests per Click im Browser aufzuzeichnen, abzuspeichern und zu einem späteren Zeitpunkt automatisch abzuspielen. Wenn die Tests erstellt werden (händisch oder per Selenium IDE) so werden die zu testende Elemente per Locator erstmal im HTML DOM Baum lokalisiert, dies geschieht meist durch eine ID, Xpath, CSS property usw, hier gilt es nun die beste Möglichkeit zu finden um die Teststabilität zu gewährleisten. Wenn Sie auf Existenz eines bestimmten HTML Elementes prüfen oder dessen Inhalt, dann möchten Sie Ihren Test nicht ändern nur weil der zu testende Screen seine Struktur geändert hat, hier gilt es den passenden Locator zu wählen. Die beste Locator Strategie ist scheinbar die Lokalisierung per ID, da diese weder von der HTML Struktur abhängt, noch an CSS gebunden ist. Allerdings hat auch sie ihre Tücken.

Zwecks Wiederverwendbarkeit, Wartbarkeit und Skalierbarkeit konzentrieren die meisten IT Abteilungen ihre Technik - wie z.B. Widgets, Utility Klassen usw - in internen Domain Frameworks; [damit ist ein Framework gemeint, das auf spezielle Problemlösungen zugeschnitten ist]. Dabei wollen die Widgets sowohl im Rahmen der eigenen Continuous Integration Prozesse getestet werden, wie aber auch in eingebettetem Zustand im Client - Projekt, das auf dem Framework aufgesetzt ist. Und schon wieder ist man in der letzten Instanz mit der ID konfrontiert. Wie geht man mit der ID um? Darf sie generiert werden? Wenn mein Domain Framework eigene Widgets bereitstellt die mit IDs versorgt werden, wie geschieht es um deren Wiederverwendbarkeit? Auf einem Screen kann ein Widget mehrmals verwendet werden, die IDs müßen jedoch immer eindeutig bleiben und stabil. Das heißt, wenn ein neues Widget dem Screen hinzugefügt wird dürfen die bereits bestehende IDs nicht geändert werden, andernfalls muss der Test angepaßt werden. Und gerade dies sollte doch vermieden werden...

Ganz Gleich auf welcher Basis das Framework aufgesetzt ist, Google Web Toolkit, Java Server Faces, DoJo, Vaadin; Selenium kann hier wunderbar eingegesetzt werden und läßt sich auch mit überschaubarem Aufwand in bestehende Frameworks integrieren. Auch die Selenium IDE kann vollständig in Ihre Umgebung integriert werden um Tests zu generieren, die mit Widgets aus Ihrem eigenen Domain Framework nahtlos funktionieren.

Integration der Selenium IDE, Selenium Remote Control, Selenium WebDriver. Ich stehe Ihnen zur Verfügung! Fragen Sie nach.