Nach dem Einbinden von checkerberry db kann mit der Erstellung der Tests begonnen werden. Bei der Erstellung des ersten Tests muss die zu verwendende DTD erzeugt werden. Das genaue Vorgehen dazu ist in Abschnitt 2.4.1.5, „Anlegen einer neuen Testdaten-DTD“ beschrieben.

Um einen Test zu schreiben, wird eine neue Testklasse erstellt. In der Setup-Phase der Testklasse muss die checkerberry db-Umgebung initialisiert werden. Dies kann entweder direkt in der Testklasse oder in einer Super-Klasse erfolgen. In dem folgenden Beispiel erfolgt dieser Schritt in der Super-Klasse, da das der häufigste Anwendungsfall ist.

package de.conceptpeople.sample.dao;

public class UserDaoIntegrationTest extends AbstractSampleTestCase {
  // Zu testendes Data Access Object (DAO)
  private UserDao dao;

  public void testGetUser() throws Exception {
    // Lesen eines Users aus der Datenbank.
    User user = dao.getUser("Homer", "Simpson");
    // Prüfen, ob der User gefunden wurde.
    assertNotNull(user);

    // Datenbanktransaktion schließen.
    persist();

    // Test-Handler holen.
    DbTestHandler testHandler = getEnvironment().getTestHandler();
    // Sicherstellen, dass die initialen Testdaten nicht verändert
    // wurden.
    testHandler.assertInitialDataUnchanged();
  }
  …
}

In dem Beispiel wird eine Testklasse mit dem Namen UserDaoIntegrationTest erzeugt, die von der abstrakten Oberklasse AbstractSampleTestCase erbt. Der Name der Testklasse setzt sich zusammen aus dem Namen der zu testenden Klasse ( UserDao ) und dem Suffix IntegrationTest. Für die getrennte Ausführung von Unit- und Integrationstests z.B. in Maven-Umgebungen, ist die Markierung der Integrationstests sinnvoll. Aus diesem Grund wird das Suffix IntegrationTest verwendet. Normale Unit-Tests, die keine Integrationsumgebung benötigen, erhalten nur das Suffix Test (siehe auch Kapitel Abschnitt 7.1.1, „Namenskonvention“).

Zunächst wird über das UserDao-Objekt der User für Homer aus der Datenbank gelesen und auf Objekt-Existenz geprüft. Danach wird die Transaktion über die Methode persist der Oberklasse geschlossen, damit etwaige Änderungen in der Datenbank persistiert werden. Die Implementierung der persist -Methode ist dabei abhängig von der Persistenzschicht des Kunden. Nach dem Abschließen der Transaktion wird überprüft, ob die initialen Testdaten unverändert sind.

Wenn dieser Test ausgeführt wird, schlägt er fehl, da noch keine initialen Testdaten vorhanden sind. Gemäß der Konvention von checkerberry db muss eine Datei de/conceptpeople/sample/dao/UserDaoIntegrationTest_testGetUser_initial.xml angelegt werden. In Maven-Projekten ist src/test/resources das richtige Verzeichnis für die XML-Testdaten. Wichtig ist, dass die Entwicklungsumgebung so eingestellt ist, dass sie XML-Dateien in den Klassenpfad kopiert, damit die Testdaten in dem Klassenpfad gefunden werden.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <USERS NAME="Bart" SURNAME="Simpson"/>
  <USERS NAME="Lisa" SURNAME="Simpson"/>
  <USERS NAME="Maggie" SURNAME="Simpson"/>
  <USERS NAME="March" SURNAME="Simpson"/>
  <USERS NAME="Homer" SURNAME="Simpson"/>
</dataset>

Das obige Beispiel zeigt mögliche Testdaten für den Test. In der Setup-Phase des Tests wird die Simpson-Familie in die Datenbank eingetragen. Die Ausführung des Tests ist jetzt erfolgreich, da das UserDao-Objekt Homer aus der Datenbank lesen kann.