Java Reference
In-Depth Information
HInWEIS:
Es gibt keine Vorgaben, wie die Tests bei so einer TDD auszusehen
haben. Es liegt in der Verantwortung des Entwicklers sich alle potenziellen Fehl-
verhalten einer Einheit im Vorfeld zu überlegen und sinnvolle Tests auszudenken.
Die Konzeption von Tests wird bei konsequenter Anwendung der TDD so lange
vorangetrieben, bis einem Entwickler keine sinnvollen weiteren Tests mehr ein-
fallen. Sie sehen damit jetzt schon, dass der Erfolg einer TDD stark von der
Erfahrung eines Programmierers abhängt.
Eine letztendlich als fehlerfrei getestete und entwickelte Unit wird bis auf Weiteres als fertig
angesehen und kann der Testfunktionalitäten entledigt oder aus dem Testszenario extra-
hiert werden.
Betrachten wir einmal beispielhat eine Konstellation, bei der so eine Vorgehensweise der
testgetriebenen Entwicklung sinnvoll wäre. Angenommen, Sie wollen in einer Webseite
eine Benutzereingabe von zwei Zahlen realisieren, die zu einer Division verwendet werden.
Es ist ofensichtlich, dass die Division durch 0 ein Problem wäre. Das gilt aber ebenso, wenn
der Anwender ein falsches Datenformat (Text) eingibt oder die Eingabefelder leer lässt.
Also erstellen Sie genau für die drei Konstellationen Testfälle. Dann setzen Sie die Funktio-
nalität um, dass keiner der drei Testfälle zu einer unbefriedigenden Situation führt. Ihr
Code wird z. B. entweder die Division durch 0 verhindern, indem eine Fehlermeldung aus-
gegeben wird, oder Sie verwenden einen Vorgabewert. Wenn ein falsches Datenformat ein-
gegeben wird, wird der Anwender eine Fehlermeldung erhalten und die Division nicht
durchgeführt, ebenso bei fehlenden Werten. Damit sollten dann alle im Vorfeld erstellten
Tests im Rahmen des JsUnit-Testing erfolgreich laufen und Sie können refaktorieren.
11.3.3■Ergebnis und Aufbau eines xunit-Tests
Wenn Sie sich entschieden haben, einen xUnit-Test durchzuführen, wird das Ergebnis eines
Tests immer äußerst primitiv, aber aussagekrätig sein. Ein xUnit-Test kann grundsätzlich
nur zwei Resultate liefern. Entweder ist der Test erfolgreich (das wird in graischen Syste-
men meist durch die Farbe Grün symbolisiert) oder nicht erfolgreich (dafür steht bei einer
visuellen Kennzeichnung fast immer die Farbe Rot).
Das Misslingen des Tests kann auf einem echten Fehler (Error) oder einem falschen Ergeb-
nis des Tests (Failure) beruhen. Beide Situationen lösen in einem xUnit-Framework eine
Ausnahme im Sinne des Exception-Handlings aus. Ein falsches Ergebnis, das in der Konzep-
tion einer Unit einkalkuliert werden kann, löst eine abfangbare Ausnahme aus, während
alle anderen Fehler vom Framework als echte Fehler geliefert werden. Das gilt natürlich
auch für das JsUnit-Framework.
Search WWH ::
Custom Search