Die wesentliche Stärke von checkerberry web liegt in der Verwendung des Modellansatzes, um nachhaltige GUI-Tests zu erstellen. Darüberhinaus gibt es einige Features, die in diesem Kapitel beschrieben werden.
Die Ausführung der checkerberry web-Tests ist zeitintensiver als die Ausführung von reinen Modultests. Insbesondere der Start der Browser-Instanzen kann einige Sekunden in Anspruch nehmen, was bei einer großen Anzahl von Tests zu merkbaren Verzögerungen führt. Aus diesem Grund unterstützt checkerberry web verschiedene Verfahren, um das Starten einer neuen Browser-Instanz zu steuern.
Beispiel 3.1. Interface NewBrowserInstancePolicy
public interface NewBrowserInstancePolicy {
/**
* Prüft, ob eine neue Browser-Instanz für den aktuellen Kontext
* verwendet werden muss.
*
* @param lastContext
* vorheriger Kontext oder <code>null</code>, wenn vorher
* keine Test-Methoden ausgeführt wurden. D.h. die aktuelle
* Methode ist der erste Test.
* @param currentContext
* aktueller Kontext.
* @param invocationCount
* Anzahl der Test-Ausführungen, die bereits mit der
* Browser-Instanz durchgeführt wurden.
* @return <code>true</code>, wenn eine neue Browser-Instanz für den
* aktuellen Kontext verwendet werden soll.<br/>
* <code>false</code>, sonst.
*/
boolean isNewBrowserInstanceRequired(WebContext lastContext,
WebContext currentContext, int invocationCount);
}Über das Interface NewBrowserInstancePolicy
wird gesteuert, wann eine neue Browser-Instanz gestartet werden muss.
Die Methode isNewBrowserInstanceRequired wird vor
jedem Testfall aufgerufen und kann anhand des aktuellen und des
vorherigen Web-Kontext entscheiden, ob eine neue Browser-Instanz
erforderlich ist. Des Weiteren wird die Anzahl der Testfälle übergeben,
die bereits mit der aktuellen Browser-Instanz gestartet wurden.
Als Standard-Verfahren wird die Klasse
DefaultNewBrowserInstancePolicy verwendet. Diese
Klasse kann konfiguriert werden oder als Basis für eigene
Konfigurationen verwendet werden. Folgende Einstellungen können
vorgenommen werden:
newBrowserForEachClassRequired: Wenn
dieser Wert auf true gesetzt ist, wird für
jede Klasse eine neue Browser-Instanz gestartet. Der Default ist
true.
browserReuseCount: Dieser Wert
definiert, wie viele Tests maximal in einer Browser-Instanz
ausgeführt werden können. Der Default ist 1. Ist der Wert 0 oder
negativ, werden beliebig viele Tests in einer Browser-Instanz
ausgeführt.
Die folgende Tabelle zeigt mögliche Konfigurationen.
Tabelle 3.1. Konfiguration von checkerberry web
newBrowserForEachClassRequired | ||
| browserReuseCount | true | false |
| 0 | Pro Klasse wird eine neue Browser-Instanz verwendet. Alle Methoden der Klasse verwenden die gleiche Instanz. | Alle Testmethoden verwenden die gleiche Browser-Instanz. |
| 1 | Das ist der Default. Pro Klasse und Methode wird eine neue Browser-Instanz verwendet. | Jede Testmethode verwendet eine eigene Browser-Instanz. |
| 5 | Pro Klasse wird eine neue Browser-Instanz verwendet. Die Instanz wird für maximal fünf Testmethoden der Klasse wiederverwendet. | Jede Browser-Instanz wird für bis zu 5 Testmethoden verwendet, wobei die Testmethoden aus unterschiedlichen Klassen stammen können. |
Es gibt Testklassen oder –methoden, die immer eine eigene
Browser-Instanz benötigen. In diesem Fall kann man die Testklasse oder
die entsprechenden Testmethoden mit der Annotation
@NewBrowserInstance markieren. Ist eine
Testklasse annotiert, wird für die Klasse eine neue Browser-Instanz
gestartet. Die Annotation an der Klasse führt jedoch nicht dazu, dass
für jede Testmethode der Klasse eine neue Browser-Instanz gestartet
wird. Ist eine Testmethode entsprechend annotiert, wird für diese
Methode eine neue Browser-Instanz gestartet.
Eine hohe Wiederverwendung der Browser-Instanzen beschleunigt die Testdurchführung. Bei einigen Browsern kann die Wiederverwendung jedoch auch zu einem hohen Speicherverbrauch im Browser führen, was die Testausführung bremsen kann. Es sollte in jedem Projekt selbst getestet werden, welcher Grad der Wiederverwendung sinnvoll ist.