Testgetriebene Entwicklung mit Access

Fehlschlagen eines Tests

Die Testmethoden Test1 und Test2 enthalten als Annahme jeweils den Ausdruck True – und da dieser nun einmal True ist, sind alle Annahmen wahr.

Wenn Sie einmal einen Test scheitern lassen möchten, ersetzen Sie einfach in einer der Assertions den Wert True durch einen Ausdruck, der nicht wahr ist – also beispielsweise False, 1=2 oder Ähnliches. Das Ergebnis sieht dann wie in Bild 5 aus – es erscheint ein roter Balken, und die Klasse, der Testnahme und die Bemerkung zu der falschen Annahme werden ausgegeben.

Entwickeln Sie!'

Nach der notwendigen Einführung in den Aufbau und den grundsätzlichen Ablauf von Tests erfahren Sie nun noch, wie Sie mit diesem Rüstzeug entwickeln sollen.

Nehmen Sie einfach einmal an, dass Sie genau wissen, was eine Funktion oder eine Routine tun soll. Eine Funktion beispielsweise soll Werte zurückliefern, eine Prozedur andere Aufgaben erledigen wie beispielsweise Daten in eine Tabelle schreiben, eine Datei löschen oder ein Formularöffnen.

Wenn Sie nun beispielsweise eine Funktion schreiben, soll diese den Eingabewerten entsprechende Ergebnisse liefern. Diese Werte können je nach der Komplexität der Funktion recht mannigfaltig sein. Wie programmieren Sie eine solche Funktion normalerweise? Richtig, Sie versuchen wahrscheinlich, diese direkt so zu programmieren, dass immer die den Eingabewerten entsprechenden Ergebnisse geliefert werden. Nach dem Erstellen der Funktion testen Sie durch, ob sie die gewünschten Ergebnisse liefert.
Doch das klappt manchmal nicht im ersten Anlauf. Sagen wir mal, nur sieben von zehn Aufrufen lieferten das richtige Ergebnis. Also noch mal ran: Funktion verändern, nicht funktionierende Aufrufe testen, funktioniert, fertig! Und, laufen die anderen Aufrufe noch? Was, das haben Sie nicht mehr geprüft – die liefen doch gerade? Na ja, der Kunde wird’s schon melden.

Und wenn die Funktion später einmal geändert werden muss, testet man selbstverständlich auch nur die Ergebnisse der neuen Eingabewerte – oder?

Wenn Sie sich hier nicht wieder erkennen und jede Funktion immer wieder manuell testen, können Sie sich eine Menge Arbeit sparen. Wenn Sie aber sagen, ja, genau, können Sie sich nicht nur eine Menge Arbeit, sondern auch eine Menge Ärger sparen – indem Sie alles dafür tun, fehlerfreien Code zu produzieren.