Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

accessUnit

Unter folgendem Link finden Sie eine ausführlichere Dokumentation im .pdf-Format, außerdem enthält der Download eine kleine Readme-Datei mit den wichtigsten Informationen.

Dokumentation

Diese Dokumentation ist derzeit eher als Kurzanleitung anzusehen.

Vorteile der testgetriebenen Entwicklung

Vorab die großen Vorteile der testgetriebenen Entwicklung:

- Sie schreiben für jede Klasse und jeden darin enthaltenen testbaren Aspekt einen Test, bevor Sie die entsprechenden Codezeilen selbst programmieren.

- Sie schreiben immer einen Test, erfüllen diesen dann durch Hinzufügen des produktiven Codes und kümmern sich erst dann um den nächsten Test. Dadurch arbeiten Sie immer nur an einer Baustelle gleichzeitig.

- Die einmal geschriebenen Tests können mit der Durchführung neu hinzugekommener Tests erneut durchgeführt werden. Somit sichern Sie sich 'nach hinten' ab und merken sofort, wenn ein bereits getestetes Feature nicht mehr funktioniert.

- Letzterer Punkt gilt gerade für eventuelle Umstrukturierungen (Refactoring): Wenn zu einem Zeitpunkt alle Tests laufen, können Sie nach Lust und Laune am Code basteln - Sie können ja jederzeit prüfen, ob noch alles funktioniert.

- Die testgetriebene Entwicklung basiert auf der Anwendung von Klassen - und damit sind nicht nur Klassenmodule, sondern auch Formulare und Berichte gemeint.

Kurzanleitung für das Testframework

Die nachfolgende Anleitung beschreibt die Vorgehensweise bei der testgetriebenen Entwicklung mit accessUnit anhand eines sehr einfachen Beispiels, um die verwendeten Klassen zu erläutern.

Um das Testframework zu verwenden, legen Sie zunächst eine Testsuite an. Diese enthält Aufrufe der AddTest-Methode, die zum Durchlaufen der einzelnen Testfixtures dient.

Kurzes Beispiel: Sie testen die Funktion Multiply einer Klasse namens clsMath, die zwei Zahlen multiplizieren soll.

Legen Sie in der Klasse clsTestmaker den Aufruf der neuen Testklasse an:

Public Sub Suite(objTestmaker As Object)

    objTestmaker.AddTest New clsMathtest

End Sub

Fügen Sie anschließend zwei Zeilen zu der Select Case-Anweisung in der Methode TestsuiteWrapper der Klasse aUTestsuites hinzu. Damit können Sie die Testsuite im Testrunner aufrufen und auswählen:

Case "clsTestsuiteMath"

      Set TestsuiteWrapper = New clsTestsuiteMath

Legen Sie dann die neue Testklasse an, kopieren Sie den Inhalt der Beispieltestklasse clsSampletest hinein und passen Sie diese so an:

Option Compare Database

Option Explicit

Dim mClass As clsMath

Public Sub Setup()

    Set mClass = New clsMath

End Sub

Public Sub Teardown()

    Set mClass = Nothing

End Sub

Public Property Get Fixturename() As String

    'Set Fixturename = Name of this class

    Fixturename = "clsMathTest"

End Property

Public Sub Test_Multiply(objTestcase As aUTestcase)

    On Error GoTo RunTest_Err

    objTestcase.Assert "Multiplicate 2x3", mClass.Multiply(2, 3) = 6

    objTestcase.Assert "Multiplicate 4x5", mClass.Multiply(4, 5) = 20

    objTestcase.Assert "Multiplicate 0x3", mClass.Multiply(0, 3) = 0

    objTestcase.Assert "Multiplicate -2x3", mClass.Multiply(-2, 3) = -6

    objTestcase.Assert "Multiplicate -2x-3", mClass.Multiply(-2, -3) = 6

    objTestcase.Assert "Multiplicate 9.7x11.8", mClass.Multiply(9.7, 11.8) = 114.46

    Exit Sub

RunTest_Err:

    objTestcase.Assert "#Error in " & Me.Fixturename, False

    Resume Next

End Sub

 

Die Methoden Setup und Teardown dienen dem Instanzieren der Klasse clsMath und dem anschließenden Freigeben der Objektvariablen.

Die Methode Test_Multiply enthält den eigentlichen Test. Der erste Teil des Aufrufs von R.Assert enthält einen Text, der beim Scheitern des Tests im Framework angezeigt wird, der zweite Teil den zu testenden Ausdruck. In dem Fall soll die erste Assertion überprüfen, ob die Funktion für die beiden Eingabewerte 2 und 3 das richtige Produkt 6 ausgibt. Die Test-Methode enthält noch weitere Assertions, die weitere Multiplikationen überprüfen.

Nach diesen Schritten öffnen Sie das erste Mal das Formular frmTestrunner. Der erste Fehler, den der Test aufdeckt, ist der, dass die zu testende Klasse noch gar nicht existiert. Um dem vorzubeugen, prüft das Formular beim Öffnen, ob die Datenbank kompiliert ist und fordert anderenfalls dazu auf, dies zu tun. Der nun ausgeführte Kompiliervorgang bringt den erwarteten Fehler: Der benutzerdefinierte Typ clsMath ist nicht definiert.

Also schnell die Klasse anlegen (noch leer), speichern und erneut kompilieren. Der nächste Fehler: Die Methode Multiply wurde nicht gefunden. Legen Sie die Methode in der Klasse clsMath an, kompilieren Sie und öffnen Sie den Testrunner erneut. Natürlich schlägt der Test fehl, da die Methode immer den Wert 0 zurückgibt. Damit stimmen zwar die Assertions, die von einem Multiplikationsergebnis von 0 ausgehen, aber alle nicht erfüllten Assertions werden im Testrunner ausgegeben:

Im nächsten Schritt fügen Sie die entscheidende Zeile hinzu:

Public Function Multiply(a, b)

    Multiply = a * b

End Function

Nach dem Kompilieren öffnen Sie erneut den Testrunner. Diesmal verläuft der Test erfolgreich:

Auf diesem Weg entwickelt man die Methode zu Ende. Wichtig ist, dass man sich im Vorhinein Gedanken über die Anforderung macht und diese in den Assertions formuliert.

Umfangreichere Klassen mit mehreren Methoden und Eigenschaften testet man genau so, und zwar jede Methode und jede Eigenschaft in einer eigenen Testmethode mit den entspechenden Assertions.

Weitere Beispiele und Informationen zum Testen von Formularen finden Sie bald an dieser Stelle.

Weitere Informationen:

Download des Frameworks

Installation des Frameworks

Ausblick

Links

Tools

In dieser Rubrik finden Sie Tools für die Anwendung mit Access.

Showplan Capturer - Abfrage-Ausführungspläne ganz einfach protokollieren, in einem eigenen Tool während der Ausführung der Abfrage anzeigen und analysieren

RTF2 (deutsch) - das bekannte RTF2-Steuerelement für Formulare und Berichte von Stephen Lebans jetzt in deutscher Sprache

OLConnector - Tool zum Umgehen der Sicherheitsabfragen bei der Automation von Microsoft Outlook

accessUnit - Unit-Testing-Framework für Microsoft Access

Procbrowser - Plugin für den VBA-Editor zum Anzeigen aller Elemente des aktuellen Moduls (Deklarationen, Prozeduren etc.)

MsgBox-Wizard - Assistent zum Erstellen von MsgBox-Anweisungen

MZ-Tools-Bibliothek - .ini-Datei, mit der Sie aus MZ-Tools heraus per Mausklick oft benötigte Funktionen zum VBA-Projekt hinzufügen können

Zeiterfassung - Zeiterfassung mit Outlook und Access, Projekt zu c't 9/2008

© 2003-2015 André Minhorst Alle Rechte vorbehalten.