Kapitel 2. Checkerberry db

Inhaltsverzeichnis

2.1. Einleitung
2.2. Funktionsweise
2.2.1. Setup-Phase
2.2.2. Test-Phase
2.2.3. Teardown-Phase
2.3. Architektur
2.4. Features
2.4.1. Verwendung von XML-Testdaten
2.4.1.1. Header-Bereich der Testdaten
2.4.1.2. Datenbereich der Testdaten
2.4.1.3. Definieren der Testdatenstruktur als DTD
2.4.1.4. Konfiguration der Testdaten-DTD
2.4.1.5. Anlegen einer neuen Testdaten-DTD
2.4.1.6. Automatische Aktualisierung der Testdaten-DTD
2.4.1.7. Tool-Unterstützung durch DTD-Verwendung
2.4.2. Zuordnung von Testdaten und tatsächliche Daten
2.4.3. Überprüfen der Ergebnisse durch Validatoren
2.4.3.1. Verwendung der Standard-Validatoren
2.4.3.2. Aktivierung / Deaktivierung von Validatoren
2.4.3.3. Anpassen der Ausführungsreihenfolge von Validatoren
2.4.3.4. Eigene Validatoren erstellen
2.4.3.5. Registrierung von Validatoren
2.4.4. Definition von modularen Testdaten
2.4.4.1. Bezeichner der INCLUDE Tabelle anpassen
2.4.5. Tabellenspalten aus Vergleichen ausschließen
2.4.6. Ignorieren von Datenbanktabellen
2.4.7. Verwendung von Parametern in Testdaten
2.4.8. Überprüfen von Datenbankrelationen mit Autoparametern
2.4.8.1. Auflösen von Autoparametern in Lookup-Keys
2.4.8.2. Manuelle Prüfung einzelner Autoparameter
2.4.9. Dynamische Testdaten durch Funktionen
2.4.9.1. Zusammenhang von Parametern und Funktionen
2.4.9.2. Maskieren von Funktionsaufrufen
2.4.9.3. Vordefinierte Funktionen
2.4.9.4. Eigene Funktionen erstellen
2.4.9.5. Definition einer eigenen Funktionssyntax
2.4.9.6. Auswertungsreihenfolge von Funktionen in Testdaten
2.4.10. Einschränken des Datenbankzugriffs
2.4.10.1. Konfiguration der Zugriffskontrolle
2.4.11. Datenbank durch Annotation leeren
2.4.12. Verwenden von leeren Tabellen
2.4.13. Erstellen von Datenbank-Dumps im XML-Testdatenformat
2.4.13.1. Feingranulares, kaskadiertes Erstellen von Datenbank-Dumps
2.4.13.2. Analysieren von Problemen mit Hilfe von Datenbank-Dumps
2.4.13.3. Erstellen von initialen Testdaten mit Hilfe von Datenbank-Dumps
2.4.13.4. Erstellen von erwarteten Testdaten mit Hilfe von Datenbank-Dumps
2.4.13.5. Encoding der Datenbank-Dumps ändern
2.4.14. Performance-Optimierung durch Caching von Tabellen
2.4.14.1. Leeren des Cache
2.4.14.2. Caching von Includes
2.4.14.3. Caching und Löschen von Tabellen
2.4.14.4. Caching von leeren Tabellen
2.4.14.5. Globales Deaktivieren des Cache
2.4.15. Analysieren mit Hilfe von Reports
2.4.15.1. Anzeigen aller Testabweichungen
2.4.15.2. Anzeigen der tatsächlichen Datenbankänderungen
2.4.15.3. Anzeigen der erwarteten Datenbankänderungen
2.4.15.4. Aufbau eines Reports am Beispiel des Diff-Reports
2.4.16. Einspielen von Testdaten temporär unterdrücken
2.4.16.1. Einspielen der initialen Testdaten unterdrücken
2.4.16.2. Einspielen der gecachten Testdaten unterdrücken
2.4.17. Aktivieren des Datenbank-Loggings
2.4.17.1. Konfigurieren des Datenbank-Loggings
2.4.18. Namenskonvention der XML-Testdaten anpassen
2.4.19. Suffixe der XML-Testdaten anpassen
2.4.20. Anpassen von DbUnit-Properties und Features
2.4.21. Verwenden des BCD-Formats
2.4.21.1. Verwenden von BCD über eine Funktion
2.4.21.2. Aktivieren von BCD als Standard-Binärformat
2.4.21.3. Aktivierung und Verwendung des binären Validators
2.5. Installation
2.5.1. Einbinden der erforderlichen Bibliotheken
2.5.1.1. Einbinden der Bibliotheken über Maven
2.5.1.2. Checkerberry db-Bibliotheken
2.5.2. Implementierung der konkreten checkerberry-db-Bridge
2.5.2.1. Anbinden der Datenbank durch den DatabaseConnector
2.5.2.2. Definition der Datenbankstruktur im DatabaseDescriptionCallback
2.5.2.3. Konfiguration von checkerberry db mit dem DbConfigurationCallback
2.5.2.4. Laden der Testdaten durch den ClasspathResourceLoader
2.5.3. Erzeugen der checkerberry db-Umgebung
2.5.3.1. Aufrufen der setUp-Methode
2.5.3.2. Einstellen der Transaktionsverwaltung
2.5.3.3. Spring-Integration
2.6. Erstellen von Tests

2.1. Einleitung

Checkerberry db ist eine Bibliothek, die den Software-Entwickler bei dem Testen von Funktionen unterstützt, die Daten innerhalb einer Datenbank lesen oder manipulieren. Komplexe Aufgaben wie das Einspielen von Testdaten in die Datenbank werden innerhalb von checkerberry db gekapselt, sodass die zu entwickelnden Tests kurz, übersichtlich und wartbar bleiben. Die folgende Grafik gibt einen Überblick über die Funktionsweise von checkerberry db.

Abbildung 2.1. Überblick Testablauf checkerberry db

Überblick Testablauf checkerberry db


Bei der Durchführung eines Tests mit checkerberry db wird zunächst die Vorbedingung für den Test hergestellt. Zu diesem Zweck wird der Inhalt der Datenbank manipuliert. Der bestehende Inhalt wird gelöscht und initiale Testdaten werden eingespielt. Die einzuspielenden Testdaten werden dabei aus einer XML-Datei eingelesen. Nach dem Einspielen der Testdaten erfolgt der Aufruf der zu testenden Funktionen. Die Funktionen greifen auf die Testdaten in der Datenbank zu und können die Daten in der Datenbank manipulieren. Danach wird geprüft, ob die Datenbank die erwarteten Werte beinhaltet. Zu diesem Zweck wird der aktuelle Datenbankinhalt mit erwarteten Testdaten verglichen. Die erwarteten Testdaten werden wie die initialen Testdaten in einer XML-Datei definiert.

Checkerberry db setzt das Open-Source-Framework DbUnit [DbUnit Homepage, 2010] ein. DbUnit stellt grundlegenden Funktionalitäten zur Verfügung, um integrierte Datenbanktests durchzuführen. Allerdings erfordert das Einbinden von DbUnit in die eigenen Projekte einen hohen Anpassungsaufwand und umfangreiche Erfahrung. Ohne das notwendige DbUnit-Know-how kann dieser Weg sehr steinig sein. Im schlimmsten Fall stellt sich erst nach einigen Monaten heraus, dass der gewählte Weg langfristig nicht gangbar ist.

Innerhalb von checkerberry db wird DbUnit ausschließlich für die Kommunikation mit der Datenbank eingesetzt. Das bedeutet insbesondere, dass der in diesem Dokument beschriebene Funktionsumfang sich ausschließlich auf Funktionen von checkerberry db bezieht.

In checkerberry db stecken mehrere Jahre an Erfahrungen, um eine möglichst einfache und nachhaltige Testentwicklung zu ermöglichen. Schließlich besteht das Ziel des Software-Entwicklers in der Testentwicklung und nicht in der Entwicklung eines neuen Testframeworks.