Die meisten Funktionen, Methoden usw. die zu testen sind werden Datenbankzugriffe durchführen. Da in einem Entwicklungssystem die Datenbasis nicht garantiert werden kann, müssen diese Daten vor dem Test erstellt werden. Ein Entwicklungssystem wird öfters neu aufgesetzt oder ein bestehender Beleg wird im Laufe der Zeit derart verändert, dass er für den Test unbrauchbar wird.
Das Unit Test Framework soll die Testaufwände reduzieren. Nun könnte man Testdaten wie Belege einmalig im Entwicklungssystem erstellen und darauf vertrauen, dass diese auch zukünftig noch für Tests in der geforderten Art vorhanden sind. Dies birgt aber die Gefahr, dass später Tests fehlschlagen, weil die Testdaten nicht passen, der getestete Code aber korrekt ist.
Aufsetzen der Testdaten
Einfache Lösung
Werden spezielle Datenbankeinträge oder Belege im Test benötigt, müssen die notwendigen Testdaten in den Fixture Methoden erstellt werden. Beispielsweise in der CLASS_SETUP oder der SETUP Methode. Die so erzeugten Datensätze müssen in den TEARDOWN Methoden wieder entfernt werden.
Das Anlegen von Datenbankeinträgen ist aber nur praktikabel, wenn sehr wenige Tabellen betroffen sind bzw. es entsprechende Funktionsbausteine zum Erzeugen und Löschen der Belege gibt.
Komplexe Lösung mit DAO Pattern
Korrekt müsste man hier das DAO Pattern verwenden. Dabei erfolgt der Datenzugriff über eine DAO Klasse mit zugehörigen Methoden. Eine DAO Klasse (Data Access Object) ist eine Klasse mit Methoden zum Datenzugriff. So kann zum Beispiel für die Tabelle MARA eine DAO Klasse mit der Methode GET_MATERIAL erstellt werden. Die Methode liefert nun die gewünschten Daten zum Material zurück. Die Datenbankzugriffe werden in der DAO Klasse gekapselt.
Die zu testende Methode greift nun auf Daten aus der Tabelle MARA zu. Anstatt die Datenbankzugriffe nun in der Methode zu implementieren, erfolgen die Zugriffe ausschließlich über ein DAO Objekt. Die zu testende Klasse verfügt über ein Attribut, welches die Referenz auf das DAO Objekt enthält.
Das folgende Bild zeigt die Verwendung der DAO Klasse durch die zu testende Business Klasse. Die Business Klasse CL_MY_BUSINESS_CLASS hat eine Methode, welche Daten aus dem Materialstamm braucht. Außerdem verfügt sie über das Attribut lo_mara_dao, welches eine Referenz auf das DAO Objekt enthält (CL_MARA_DAO). Die Methode my_business_method verwendet nun die Methode GET_MATERIAL der DAO Klasse statt direkt auf der Datenbank zu lesen. Statt dessen erfolgt der Zugriff in der Methode GET_MATERIAL.
Innerhalb der Testklasse gibt es ebenfalls eine DAO Klasse, welche die Testdaten zurück liefert aber keinen Datenbankzugriff vornimmt. Die Testdaten werden in dieser Dummy DAO Klasse statisch erzeugt.
Innerhalb der Testmethode wird nun der zu testenden Klasse eine Referenz auf die Dummy DAO Klasse übergeben. Die zu testende Klasse ruft nun die Methode GET_MATERIAL der Dummy DAO Klasse auf und erhält immer die gleichen Materialdaten.
Das komplette Vorgehen wird in diesem SCN Artikel beschrieben.
Schlussfolgerung
Damit das Pattern korrekt funktioniert, muss bei bestehenden Methoden, Fubas, Bapis etc die Business Logik an das DAO Pattern angepasst werden. Praktikabler ist daher das erstellen der notwendigen Datensätze in den Fixture Methoden. Das DAO Pattern empfiehlt sich nur bei gänzlich neu implementierten Funktionen.
Im letzten Artikel der Serie zeige ich noch die systemweiten Einstellungen zu dem Unit Test Framework.