In der Test-Phase wird der eigentliche Test in Form einer Methode aufgerufen. Da die initialen Testdaten zu diesem Zeitpunkt bereits in der Datenbank vorhanden sind, kann sich der Software-Entwickler auf die fachlichen Aspekte des Tests konzentrieren. In der Regel werden Methoden aufgerufen, die Daten aus der Datenbank lesen oder manipulieren. Die Aufgabe des Tests besteht somit zum einen darin, die Rückgabewerte der Methoden zu überprüfen. Zum anderen muss überprüft werden, ob der Zustand in der Datenbank korrekt ist.

In dem aktuellen Beispiel wird die Test-Methode testInsertUser aufgerufen. Diese Methode testet, ob die Methode save in der Klasse UserDao einen neuen Eintrag in der Datenbank anlegt. Zu diesem Zweck wird zunächst ein neues User-Objekt mit dem Namen „Homer Simpson“ und dem Geburtsdatum „16.09.1946“ erzeugt. Dieses Objekt wird an die save-Methode des UserDao-Objekts übergeben. Der Rückgabewert der save-Methode wird über die JUnit-Methode assertTrue validiert. Wenn diese Prüfung erfolgreich ist, wird die Korrektheit des Datenbankinhalts geprüft. 

Zur Überprüfung des Datenbankinhalts bietet checkerberry db im Wesentlichen drei Methoden an: assertInitialDataUnchanged, assertEqualsInitial und assertEqualsExpected.

Die Methode assertInitialDataUnchanged stellt sicher, dass die initialen Testdaten in der Datenbank nicht verändert wurden. In dem aktuellen Beispiel prüft checkerberry db, ob die Einträge für Marge, Bart, Lisa und Maggie Simpson in der Datenbank mit den Werten aus den initialen Testdaten übereinstimmen. Dies ist wichtig beim Testen von lesenden Funktionen, da diese Funktionen den Datenbankinhalt nicht verändern dürfen. Gerade bei der Verwendung von Hibernate ist diese Überprüfung wichtig, da Änderungen in der Hibernate-Session auch bei lesenden Datenbankzugriffen eine Änderung in der Datenbank hervorrufen können. Das Hinzufügen neuer Datensätze wird von der Methode assertInitialDataUnchanged ignoriert. Es ist also zulässig, einen neuen Datensatz anzulegen und mit dieser Methode zu prüfen, ob die bereits bestehenden Datensätze von dieser Änderung unberührt blieben.

Um zu überprüfen, ob die Datenbank gar nicht verändert wurde, steht die Methode assertEqualsInitial zur Verfügung. Dies betrifft jedoch nur die in der mit „initial“ bezeichneten XML-File angegebenen Tabellen. Nicht aufgeführte Tabellen werden nicht überprüft.

Die Methode assertEqualsExpected vergleicht den aktuellen Datenbankinhalt mit den erwarteten Testdaten. Die erwarteten Testdaten werden analog zu den initialen Testdaten definiert. Allerdings wird für erwartete Testdaten das Suffix result anstelle von initial verwendet.

Für das aktuelle Beispiel werden die erwarteten Testdaten in der Datei UserDaoTest_testInsertUser_result.xml definiert. Diese Datei hat den folgenden Inhalt:

<?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" BIRTHDATE="2009-03-18"/>
  <USERS NAME="Lisa" SURNAME="Simpson" BIRTHDATE="2009-03-18"/>
  <USERS NAME="Maggie" SURNAME="Simpson" BIRTHDATE="2009-03-18"/>
  <USERS NAME="Marge" SURNAME="Simpson" BIRTHDATE="2009-03-18"/>
  <USERS NAME="Homer" SURNAME="Simpson" BIRTHDATE="1946-09-16"/>
</dataset>

Anhand der erwarteten Testdaten stellt checkerberry db sicher, dass die Datenbanktabelle USERS fünf Einträge mit den definierten Spaltenwerten beinhaltet.

Die Methode assertEqualsExpected überprüft nur Tabellen, die in den erwarteten Testdaten angegeben sind. Für das Beispiel bedeutet dies, dass in der Datenbank neben der USERS-Tabelle weitere Tabellen mit beliebigen Werten definiert sein können. Der Inhalt dieser Tabellen wird jedoch nicht geprüft, da sie nicht in den erwarteten Testdaten aufgeführt sind.