Testgetriebene Entwicklung mit Access
Der Test treibt
„Testgetrieben“ entwickeln bedeutet, dass man zu allem, was man entwickelt, zunächst einen Test schreibt. Und wenn Sie die Funktion eines Elements ändern möchten, ändern Sie zunächst den zugrunde liegende Test.
Dabei ist es sehr wichtig, dass Sie den Test nach dem Schreiben zunächst ausführen und damit fehlschlagen lassen, denn nur so können Sie sicher sein, dass der Test auch funktioniert. Erst wenn der Testrunner den roten Balken angezeigt hat, implementieren Sie die durch den Test angekündigte Funktionalität und weisen deren Richtigkeit durch einen grünen Balken nach. Außerdem sollten Sie immer den einfachsten Weg zum erfolgreichen Bestehen des anstehenden Tests wählen.
Für das folgende Beispiel verwenden Sie die bereits vorhandene Testmethode Test1. Angenommen, Sie möchten eine Funktion schreiben, die genau die gleiche Aufgabe wie die DLookup- Funktion hat, zum Beispiel weil die DLookup- Funktion mitunter etwas langsam ist und Sie sich einen Ersatz bauen möchten.
Mit der testgetriebenen Entwicklung geht das ganz einfach: Legen Sie fest, wie die Funktion heißen soll (etwa FastDLookup) und beschreiben Sie anhand von Assertions, welche Ergebnisse die Funktion bei welchem Eingabeparameter liefern soll. Dazu benötigen Sie zunächst einmal ein paar Testdaten. Die Testdaten müssen exakt definiert sein, da sich bei Änderungen der Testdaten während des Tests oder zwischen zwei Tests unter Umständen auch die Testergebnisse ändern können. Daher sollten Sie vor jedem Test sicherstellen, dass die gewünschten Testdaten vorhanden sind. Dies geschieht optimalerweise in der Setup-Methode der Testklasse.
In der Teardown-Methode können Sie die Daten und/oder Tabellen wieder löschen beziehungsweise entfernen.
Aus Platzgründen kann dieser Beitrag das Anlegen von Testdaten nicht behandeln, so dass Sie für den ersten Test einfach die Personal-Tabelleder Nordwind-Datenbank verwenden.
Schreiben Sie dann in die Methode Test1, was Sie von der Funktion FastLookup erwarten (die im Übrigen die gleichen Parameter wie das Pendant DLookup enthalten soll):
Die Funktion soll den Wert 1 für die Personal- Nr ausgeben, wenn als Kriterium Nachname = 'Davolio' angegeben wird. Die Assertion sieht wie folgt aus:
objTestcase.Assert "Datensatz nach Nachname
ermitteln", FastLookup("[Personal-Nr]", "Personal",
"Nachname = 'Davolio'") = 1
Löschen Sie die bereits vorhandenen Assertions und auch die zweite Testklasse (Test2), kompilieren Sie das Projekt und – schon weist Sie ein Kompilierfehler darauf hin, dass die Funktion FastLookup gar nicht definiert ist. Natürlich ist sie das nicht! Sie haben, genau wie geplant, erstmal einen Test mit einer Anforderung geschrieben, der erwartungsgemäß gescheitert ist (wenn auch das Scheitern nicht im Testrunner-Formular angezeigt wurde). Also fügen Sie eine Funktion namens FastLookup in ein Standardmodul ein und legen deren Parameter fest:
Public Function FastLookup(strField As String,
strTable As String, strCriteria As String) As Variant
End Function