Bei der Definition der erwarteten Testdaten gibt es häufig das Problem, dass einige Werte zum Zeitpunkt der Testerstellung nicht feststehen. Dies umfasst zum Beispiel generierte IDs oder auch technische Zeitstempel, die in die Datenbank eingefügt werden. Es gibt zwei Möglichkeiten, mit dieser Situation umzugehen.

Eine Lösung besteht wie in Abschnitt 2.4.5, „Tabellenspalten aus Vergleichen ausschließen“ beschrieben darin, die Spalten aus dem Vergleich auszuschließen. Dieser Weg ist dann sinnvoll, wenn die entsprechenden Daten nicht im Fokus des Tests stehen.

Wenn die Prüfung von dynamischen Werten für den Test relevant ist, ist der Ausschluss der Spalte keine sinnvolle Maßnahme. Für diese Situationen stellt checkerberry db die Möglichkeit zur Verfügung, Parameter zu definieren.

<dataset>
  <!-- Die Spalte ID enthält den Parameter userId. -->
  <USERS ID="${userId}" NAME="Montgomery" SURNAME="Burns"/>
</dataset>

Das obige Beispiel zeigt, wie Parameter in den erwarteten Testdaten definiert werden können. In diesem Fall wird der Parameter userId als ID für die entsprechende Zeile der Tabelle USERS definiert. Die Definition von Parametern erfolgt durch die Zeichen ${ , gefolgt von dem Parameternamen und einer abschließenden geschweiften Klammer }.

public void testSaveUser() throws Exception {
  …
  // Speichern eines neuen User-Objekts.
  userDao.save(user);
  …
  // Holen des Testhandlers.
  DbTestHandler testHandler = getEnvironment().getTestHandler();
  // Holen des Parameter-Kontextes.
  ParameterContext parameterContext = testHandler.getParameterContext();
  // Wenn das User-Objekt in der Datenbank gespeichert wird, wird in
  // der Datenbank eine neue ID vergeben, die dann in dem User-Objekt
  // gesetzt wird. Dieser Wert wird dem Parameter userId zugewiesen.
  parameterContext.addParameter("userId", user.getId());
  …
}

In den ParameterContext können beliebig viele Parameter eingefügt werden. Das obige Beispiel zeigt eine typische Situation im Hibernate-Umfeld: Ein User-Objekt wird in der Datenbank gespeichert. Erst nach der Speicherung ist die ID des Objekts verfügbar und kann erst dann für den Vergleich genutzt werden. An dieser Stelle ist die Entscheidung des Software-Entwicklers gefragt: Muss die Spalte ID beim Vergleich berücksichtigt werden oder kann ein alternativer Lookup-Key gewählt werden? Die Antwort auf die Frage bestimmt, ob mit Parametern oder auszuschließenden Spalten gearbeitet werden sollte.

Die erwarteten Testdaten werden innerhalb der Methode assertEqualsExpected eingelesen. In den Testdaten wird dabei nach enthaltenen Parametern gesucht, die dann durch die entsprechenden Werte aus dem Parameter-Kontext ersetzt werden. Die Parameter müssen aus diesem Grund in der Testmethode vor dem Aufruf der Methode assertEqualsExpected hinzugefügt werden.

Parameter stellen eine einfache Möglichkeit zur Dynamisierung der Testdaten dar. Da bei einer zu intensiven Nutzung jedoch Übersichtlichkeit und damit Wartbarkeit der Tests leiden, bietet checkerberry db mit den Funktionen noch einen mächtigeren Ansatz, dies zu bewerkstelligen. Nähere Informationen finden sich in Abschnitt 2.4.8, „Überprüfen von Datenbankrelationen mit Autoparametern“ und Abschnitt 2.4.9, „Dynamische Testdaten durch Funktionen“.