Für die Entwicklung und Durchführung der automatisierten Integrationstests ist die Erzeugung einer checkerberry db-Umgebung erforderlich. Die checkerberry db-Umgebung steuert das Einspielen der Testdaten und stellt dem Entwickler die erforderlichen Schnittstellen zur Verfügung.
Die checkerberry db-Umgebung wird in der Setup-Phase erzeugt und lokal in der Testklasse gespeichert. Um diesen Schritt nicht für jeden Test zu wiederholen, sollte er in einer Oberklasse des Tests erfolgen. Über eine Getter-Methode wird den abgeleiteten Tests die Umgebung zur Verfügung gestellt.
Beispiel 2.73. Erzeugen der checkerberry db-Umgebung
public void setUp() { // Erstellen des Database-Connectors für die checkerberry db-Bridge SampleDatabaseConnector connector = new SampleDatabaseConnector(); // Callback für die Datenbankbeschreibung erstellen. SampleDatabaseDescriptionCallback databaseDescriptionCallback = new SampleDatabaseDescriptionCallback(); // Callback für die Konfiguration von checkerberry db erstellen. SampleConfigurationCallback configurationCallback = new SampleConfigurationCallback(); // Checkerberry db-Umgebung mit den Bridge-Komponenten erzeugen. Die // Member-Variable environment wird allen erbenden Klassen über den Getter // getEnvironment() zur Verfügung gestellt. environment = CheckerberryDb.getInstance().getEnvironment( connector, databaseDescriptionCallback, configurationCallback); // Checkerberry db-Umgebung für den Test initialisieren. // Die Parameter sind abhängig von dem verwendeten Testframework environment.setUp(...); }
Für die Erzeugung der Umgebung sind, wie in den vorherigen
Kapiteln beschrieben, einige anwendungsspezifische Informationen
erforderlich. Dies umfasst einen optionalen
DatabaseConnector
für die Anbindung von checkerberry
db an die zu verwendende Datenbank. Zusätzlich wird ein
DatabaseDescriptionCallback
für die
Datenbankbeschreibung benötigt. Für die Konfiguration von checkerberry
db wird ein DbConfigurationCallback
verwendet.
Nach der Erzeugung der benötigten Klassen wird die checkerberry
db-Umgebung über das Singleton CheckerberryDb
erzeugt. Danach wird die Methode setUp
der
checkerberry db-Umgebung aufgerufen, um initiale Testdaten zu ermitteln
und einzuspielen. Der Methode muss zumindest die aktuelle Instanz der
Testklasse übergeben werden. Ob weitere Parameter für den Aufruf der
setUp
-Methode erforderlich sind, hängt von dem
verwendeten Testframework ab. In Abschnitt 2.5.3.1, „Aufrufen der setUp-Methode“ wird die
setUp
-Methode für die unterschiedlichen
Testframeworks beschrieben.
Beispiel 2.74. Setup-Methoden des checkerberry db-Environments
public interface { void setUp(Object testInstance); void setUp(Object testInstance, Method testMethod); void setUp(Object testInstance, String testMethodName); … }
Das Interface CheckerberryDbEnvironment
stellt
drei Setup-Methoden zur Verfügung. Die Setup-Methoden verwenden immer
die aktuelle Instanz der Testklasse. Darüber hinaus kann auch der Name
der aktuellen Testmethode angegeben werden. Dies ist z.B. für die
Verwendung von TestNG und anderen Testframeworks relevant.
Die Erzeugung der checkerberry db-Umgebung erfolgt über das
Singleton CheckerberryDb
. Der Grund hierfür besteht
darin, dass alle Tests auf die gleiche checkerberry db-Umgebung
zugreifen müssen. Aus diesem Grund verwaltet das Singleton-Objekt die
Referenz auf die checkerberry db-Umgebung und liefert die gleiche
Objektinstanz an alle Tests zurück.
Die checkerberry db-Umgebung selbst darf kein Singleton sein, da die Initialisierung von mehreren checkerberry db-Umgebungen in einem Test möglich ist, wenn mehr als eine Datenbank für die Durchführung der Tests benötigt wird. Aus diesem Grund wird an dieser Stelle das beschriebene Service Locator Pattern [Service Locator Pattern, 2010] verwendet.
In der Teardown-Phase wird die Methode tearDown
der checkerberry db-Umgebung aufgerufen. Das folgende Code-Beispiel
zeigt eine typische Implementierung.
Beispiel 2.75. Beenden der checkerberry db-Umgebung nach einem Test
public void tearDown() { // Checkerberry db-Umgebung über tearDown informieren. environment.tearDown(); // tearDown an Basisklasse aufrufen. super.tearDown(); // Sicherstellen, dass das Environment nach Testende aufgeräumt werden kann environment = null; }
Checkerberry db verwendet zahlreiche Konventionen, um den Konfigurationsaufwand gering zu halten. Die Konventionen greifen dabei regelmäßig auf den Namen der aktuellen Testklasse und den Namen der aktuellen Testmethode zurück. Abhängig vom verwendeten Testframework gibt es unterschiedliche Methoden, auf diese Information zuzugreifen. Während das checkerberry test center in der Lage ist, sie in JUnit3-Umgebungen komplett selbstständig zu ermitteln, erfordert dies in JUnit4- und TestNG-Umgebungen ein wenig zusätzlichen Aufwand seitens des Entwicklers.
In den nächsten Abschnitten wird auf die Erfordernisse der unterschiedlichen Umgebungen detailliert eingegangen.
Bei der Verwendung von JUnit3 ist die Ermittlung des aktuellen
Testmethodennamens einfach möglich, da er über die Methode
getName
direkt an der Instanz der Testklasse
ermittelt werden kann. Bei der Erzeugung der checkerberry
db-Umgebung ist daher lediglich eine Referenz auf die Testinstanz
erforderlich. Folgendes Beispiel zeigt die wesentlichen Aspekte der
Erzeugung.
Beispiel 2.76. Ermittlung Testmethodennamen unter JUnit3
private CheckerberryDbEnvironment environment; public void setUp() { // Die genaue Erstellung der Umgebung ist hier nicht relevant. environment = CheckerberryDb.getInstance().getEnvironment(…); environment.setUp(this); } public void tearDown() { environment.tearDown(); environment = null; }
Bei dem Setup der Umgebung muss lediglich die Referenz auf die Testinstanz angegeben werden. Den Namen der aktuellen Testmethode ermittelt checkerberry db dann selbständig.
Mit der Einführung von JUnit4 wurde das Feature zur einfachen Ermittlung der aktuellen Testmethode nicht mehr zur Verfügung gestellt. Dieser Fehler wurde mit der JUnit Version 4.7 wieder behoben. Für die Verwendung eines JUnit Version zwischen 4 und 4.7 muss man auf die Hilfe zusätzlicher Frameworks zurückgreifen. Wenn ein Upgrade auf die aktuelle JUnit-Version nicht möglich ist, empfehlen wir die Verwendung von Spring. Folgendes Beispiel zeigt die Konfiguration.
Beispiel 2.77. Ermittlung Testmethodennamen unter JUnit4 und Spring
@RunWith(SpringJUnit4ClassRunner.class) //Spring Konfiguration @ContextConfiguration(locations = { "/application-context-test.xml" }) //Der erste für DependencyInjection, der zweite um checkerberry db //mit dem Namen der Testmethode zu versorgen. @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class, TestMethodNameResolvingExecutionListener.class }) public class AbstractJUnit4SpringTest { private CheckerberryDbEnvironment environment; @Before public void setUp() { // Die genaue Erstellung der Umgebung ist hier nicht relevant. environment = CheckerberryDb.getInstance().getEnvironment(…); environment.setUp(this); } @After public void tearDown() { environment.tearDown(); environment = null; } }
Die JUnit-Annotation @RunWith
definiert,
mit Hilfe welcher Klasse der Test ausgeführt wird. In diesem
konkreten Fall wird Spring und JUnit4 verwendet. Über die
Spring-Annotation @ContextConfiguration
wird der
zu verwendende Application-Kontext definiert. Dieser
Application-Kontext enthält im Beispiel auch Teile der
Bridge-Implementation.
Über die Spring-Annotation
@TestExecutionListeners
werden zwei Listener
registriert, die vor der Testausführung involviert werden. Der
Spring-Listener
DependencyInjectionTestExecutionListener
ist für
die Bearbeitung des Application-Kontexts zuständig. Der Listener
TestMethodNameResolvingExecutionListener
dient
der Versorgung von checkerberry mit dem Test-Methodennamen.
Bei dem Setup der Umgebung muss lediglich die Referenz auf die Testinstanz angegeben werden.
Ab der JUnit Version 4.7 wurde die Ermittlung des Namens der aktuellen Testmethode wieder ermöglicht. Das folgende Beispiel zeigt das erforderliche Vorgehen.
Beispiel 2.78. Ermittlung Testmethodennamen unter JUnit4.7
@Rule public MethodNameDeterminationRule rule = new MethodNameDeterminationRule(); private CheckerberryDbEnvironment environment; @Before public void setUp() { // Die genaue Erstellung der Umgebung ist hier nicht relevant. environment = CheckerberryDb.getInstance().getEnvironment(…); environment.setUp(this); } @After public void tearDown() { environment.tearDown(); environment = null; }
Durch die Verwendung der Annotation @Rule
wird der Name der aktuellen Testmethode ermittelt. Bei dem Setup der
Umgebung muss lediglich die Referenz auf die Testinstanz angegeben
werden. Den Namen der aktuellen Testmethode ermittelt checkerberry
db dann selbständig.
Anmerkung: die
@Rule
-Annotation wird von JUnit4 erst ab Version
4.7 bereitgestellt. Sollten Sie eine ältere JUnit4-Version
verwenden, so empfehlen wir das Update auf eine aktuelle
Version.
Bei der Verwendung von TestNG kann der Name direkt in der Setup-Phase übergeben werden. Folgendes Beispiel zeigt die wesentlichen Aspekte der Erzeugung.
Beispiel 2.79. Ermittlung Testmethodennamen unter TestNG
private CheckerberryDbEnvironment environment; @BeforeMethod public void setUp(Method testMethod) { // Die genaue Erstellung der Umgebung ist hier nicht relevant. environment = CheckerberryDb.getInstance().getEnvironment(…); environment.setUp(this, testMethod); } @AfterMethod public void tearDown() { environment.tearDown(); environment = null; }
Die TestNG-Annotation @BeforeMethod
ermöglicht die Angabe eines Method-Objekts als Parameter. TestNG
sorgt dann zur Ausführungszeit dafür, dass der Parameter mit der
aktuellen Testmethode aufgerufen wird. Bei dem Setup der Umgebung
muss dann die Referenz auf die Testinstanz und auf die aktuelle
Testmethode angegeben werden. Den Namen der aktuellen Testmethode
ermittelt checkerberry db dann selbständig.
Selbstverständlich lässt sich checkerberry db auch in anderen Testframeworks als den genannten einsetzen. Die Ermittlung des Namens der aktuellen Testmethode ist von Framework zu Framework unterschiedlich. Das checkerberry test center stellt keine Funktionalität bereit, um den Namen der Testmethoden in anderen Frameworks zu ermitteln.
Wenn der aktuelle Test-Methodenname ermittelt wurde, übergibt
man ihn der setUp
-Methode als zusätzlichen
Parameter, um ihn checkerberry db direkt mitzuteilen:
environment.setUp(this, "testMethod");