6.2.9. Muss ich immer eine DTD für die Testdaten verwenden?

Bei der Verwendung von checkerberry db ist die Verwendung einer DTD vorgeschrieben. Checkerberry ist an dieser Stelle somit restriktiver als DbUnit. Warum ist das so?

Die DTD definiert die Struktur der zu testenden Datenbank. Sie enthält die Namen der Tabellen in der Reihenfolge ihrer Abhängigkeiten, definiert für jede Tabelle die vorhanden Spalten und legt fest, welche Spalten Pflichtangaben (not nullable) enthalten.

DbUnit unterstützt bei der Überprüfung von Testdaten mit der Datenbank zwei verschiedene Vorgehensweisen. Zum einen kann eine DTD verwendet werden. DbUnit prüft dann für jede angegebene Tabelle die Gleichheit der Werte für alle Spalten.

Zum anderen kann DbUnit ohne DTD verwendet werden. In dieser Situation werden die zu überprüfenden Spalten einer Tabelle direkt aus den Testdaten ermittelt. Der erste Eintrag der Testdaten legt fest, welche Spalten bei der Überprüfung berücksichtigt werden sollen. Enthalten die Testdaten zum Beispiel vier Datensätze für die Tabelle USERS und der erste Eintrag beinhaltet die Spalten ID, NAME und SURNAME, dann werden nur diese drei Spalten überprüft – auch für die drei folgenden Datensätze. Der Vorteil dieses Vorgehens besteht darin, dass dynamisch festgelegt werden kann, welche Spalten überprüft werden sollen. Der Nachteil liegt darin, dass dieses Verhalten sehr intransparent ist.

Es existieren im Wesentlichen zwei Probleme bei dem Verzicht auf eine DTD. Das erste Problem besteht darin, dass durch die Definition des ersten Testdatensatzes aus Versehen Spalten von der Überprüfung ausgeschlossen werden. In dem obigen Beispiel würden die Werte der Spalte BIRTHDATE nicht geprüft werden, wenn sie in den drei folgenden Datensätzen verwendet werden würden. In diesem Fall würde der Test erfolgreich durchlaufen, obwohl Abweichungen in Spalten vorhanden sind. Das zweite Problem betrifft die Behandlung von null-Werten. Innerhalb der Testdaten werden null-Werte dadurch definiert, dass die zugehörigen Spalten in dem Datensatz nicht aufgenommen werden. Dies führt zu einer doppelten Bedeutung nicht vorhandener Spalten. In dem ersten Datensatz einer Tabelle bedeuten nicht vorhandene Spalten, dass diese nicht überprüft werden sollen. In den folgenden Datensätzen bedeuten sie, dass die Werte null sind. Diese Situation führt schnell zu Problemen, wenn in dem ersten Datensatz eine Spalte einen null-Wert enthält, der geprüft werden soll. Diese Situation tritt sehr häufig ein und kann ohne DTD nicht gelöst werden.

Aus der Erfahrung heraus kann DbUnit aus den oben beschriebenen Gründen sinnvoll nur mit einer DTD verwendet werden. Anderenfalls ergeben sich große Fehlerpotentiale oder wilde Work-Arounds, die der Verständlichkeit der Tests und der Testdaten schaden. In der DbUnit-Dokumentation wird im Übrigen ebenfalls die Verwendung einer DTD empfohlen.

Darüber hinaus ergeben sich durch die Verwendung einer DTD weitere Vorteile. Die Testdaten können bereits während der Entwicklung auf Gültigkeit validiert werden. Des Weiteren bieten die gängigen Entwicklungsumgebungen Auto-Vervollständigungen bei der Erstellung der XML-Testdaten an, sodass die Erstellung der Testdaten deutlich beschleunigt wird.