3.2. Funktionsweise

Der allgemeine Ablauf von Unit-Tests in den drei Phasen (Setup, Test und Teardown) wurde bereits im Kapitel Abschnitt 1.3.3.1, „Test-Ablauf“ beschrieben. Die folgenden Abschnitte beschreiben das Verhalten von checkerberry web in diesen Phasen.

3.2.1. Setup-Phase

In der Setup-Phase werden die Voraussetzungen für die Durchführung der Tests geschaffen. Zu diesem Zweck muss die checkerberry web-Umgebung erzeugt werden, was ausführlich in Abschnitt 3.5.2, „Erzeugen der checkerberry web-Umgebung“ beschrieben wird. Die folgende Abbildung beschreibt die Auswirkungen, die die Erzeugung der checkerberry web-Umgebung bei der Verwendung von Selenium RC hat.

Abbildung 3.2. Checkerberry web Setup-Phase

Checkerberry web Setup-Phase


Die checkerberry web-Umgebung wird in der Setup-Phase durch einen Selenium-Client gestartet, der über eine Bibliothek in den Test eingebunden ist. Durch die Erzeugung der checkerberry web-Umgebung wird eine weitere Selenium-Komponente, der Selenium RC Server, gestartet. Bei dem Server handelt es sich um ein Software-Programm, das zwei weitere Komponenten beinhaltet: Einen Browser-Launcher und einen HTTP-Proxy. Der Browser-Launcher startet zwei neue Browserfenster. In einem Browserfenster wird die HTML-Seite RemoteRunner.html geöffnet, die den Selenium-Core darstellt. In dem anderen Browserfenster wird die zu testenden Anwendung (AUT = Anwendung unter Test) gestartet. Korrekterweise handelt es sich bei der Anwendung unter Test um eine zu testende Webseite, die von einem Webserver geladen wurde. Die URL dieser Webseite wurde der checkerberry web-Umgebung beim Start übergeben.

Der Selenium-Core besteht aus einer Sammlung von JavaScript-Funktionen, die zur Kommunikation mit der zu testenden Anwendung benötigt werden. Die Kommunikation der verschiedenen Komponenten wird in der Test-Phase beschrieben.

Beim Start der Browserfenster sorgt Selenium dafür, dass der HTTP-Proxy aus dem Selenium RC Server in den Browsern verwendet wird. Dieses Verfahren wird „Proxy Injection“ [Proxy Injection, 2010] genannt und ist eine Lösung zur Umgehung der „Same Origin Policy“ [Same Origin Policy, 2010]. Die Bedeutung dieses Vorgehens wird in dem nächsten Kapitel beschrieben, da die Problematik anhand der Test-Phase besser verdeutlicht werden kann.

Die Kommunikation zwischen Test und Browser ist bei der Verwendung von WebDriver deutlich einfacher. Dies liegt daran, dass der Browser selbst ein WebDriver-Plug-In enthält, das die Kommunikation mit dem Test ermöglicht.