Checkerberry db vergleicht XML-Testdaten mit Daten aus der Datenbank. Aus diesem Grund ist es erforderlich, dass checkerberry db die Struktur (Tabellen und Spalten) der verwendeten Datenbank kennt. Die Definition der erforderlichen Informationen erfolgt über eine Implementation des Interfaces DatabaseDescriptionCallback. Folgendes Code-Beispiel enthält das Interface.

/**
 * Callback-Interface zur Definition der Datenbankbeschreibung.
 */
public interface DatabaseDescriptionCallback {

  /**
   * Erzeugt die Datenbankbeschreibung, indem für alle Tabellen die Lookup Key
   * Spalten definiert werden.
   *
   * @param databaseDescription
   *            zu initialisierende Datenbankbeschreibung.
   * @see DatabaseDescription#addTableDescription(String, String...)
   */
  void createDatabaseDescription(DatabaseDescription databaseDescription);
}

Da die Datenbankstruktur für jede System-Umgebung unterschiedlich ist, gibt es keine Basisklasse für die Implementierung des Interfaces. Das folgende Code-Beispiel zeigt eine exemplarische Implementation.

/**
 * Spezielles Callback zur Definition der Datenbank-Struktur.
 */
public class SampleDatabaseDescriptionCallback
    implements DatabaseDescriptionCallback {

  /**
   * {@inheritDoc}
   */
  public void createDatabaseDescription(
      DatabaseDescription databaseDescription) {

    // Tabelle USERS hat die Spalten NAME und SURNAME als Lookup-Keys.
    databaseDescription.addTableDescription("USERS", "NAME", "SURNAME");
    // Tabelle COUNTRIES hat die Spalte CODE als Lookup-Key. Die Tabelle
    // kann im Cache gespeichert warden.
    databaseDescription.addTableDescription("COUNTRIES", Cacheable.Yes,"CODE");
    // Tabelle NOTES hat die Spalte ID als Lookup-Key. Die
    // Spalte UPDATE_DATE wird bei einem Vergleich nicht berücksichtigt.
    databaseDescription.addTableDescription("NOTES", "ID")
        .addExcludedColumns("UPDATE_DATE");
  }
}

Dem Interface DatabaseDescriptionCallback wird die Klasse DatabaseDescription übergeben, um dort alle Informationen zur Datenbankstruktur zu speichern. Das Interface ist als Callback realisiert, um den Erzeugungszeitpunkt der Datenbankbeschreibung in checkerberry db verwalten zu können. Jede Test-Methode verwendet eine eigene Instanz der Datenbankbeschreibung, sodass das Callback vor der Durchführung jeder Testmethode aufgerufen wird. Innerhalb des Callbacks werden Informationen zu allen Datenbanktabellen angegeben, deren Inhalt durch checkerberry db geprüft werden soll. Die wichtigste Angabe ist die Definition der Lookup-Keys für jede Tabelle. Anhand der Lookup-Keys kann checkerberry db eine Zuordnung zwischen Testdaten und den Daten der Datenbank herstellen.

Neben den Lookup-Keys kann für jede Datenbanktabelle eine Liste von Spaltennamen angegeben werden, die bei dem Vergleich von Testdaten mit den Daten der Datenbank nicht berücksichtigt werden. Es handelt sich dabei in der Regel um dynamische und/oder technische Informationen wie z.B. technische Zeitstempel, die den Änderungszeitpunkt eines Datensatzes anzeigen.

Des Weiteren ist die Markierung einer Datenbanktabelle als cacheable möglich. Im Gegensatz zu den Lookup Keys und den „Excluded Columns“ kann die Caching-Eigenschaft nur in dem Callback-Interface gesteuert werden. Die Modifikation in einer Testmethode ist für die Caching-Eigenschaft nicht möglich. Da die Caching-Eigenschaft bereits in der Setup-Phase, also vor der Durchführung einer Testmethode ausgewertet wird, hat die Modifikation in der Testmethode keine Auswirkungen auf die aktuelle Testmethode. Aus diesem Grund wird die Angabe der Caching-Eigenschaft nur in dem Callback-Interface erlaubt.

Es ist im Übrigen nicht erforderlich, sofort bei der Einbindung von checkerberry alle Tabellenbeschreibungen einzutragen. Es ist ausreichend, wenn man die Beschreibungen für die Tabellen definiert, die tatsächlich getestet werden. In der Praxis sieht es so aus, dass das Interface nach und nach implementiert wird.