Erweiterte Tools, Hintergründe & Techniken - JavaScript: Die Universelle Sprache zur Web-Programmierung - page 332

deln, damit Sie sich überhaupt etwas darunter vorstellen können. Das Unit-Testing hat sich
ursprünglich überwiegend im Java-Umfeld entwickelt und wurde unter dem Begrif JUnit
bekannt. Darunter versteht man im engeren Sinn ein Framework zum Testen von Java-Pro-
grammen bzw. deren Bestandteilen (Units). Mittlerweile existieren solche Test-Frameworks
für viele Programmiersprachen, so dass man von einem universellen Test-Framework spre-
chen und es unter dem Begrif xUnit zusammenfassen kann.
HInWEIS: Das JsUnit-Framework ist ganz nah an den Möglichkeiten und Ver-
haltensweisen des Java-Vorbilds in JUnit angelegt, soweit man mit JavaScript
überhaupt Dinge aus Java nachbilden kann. Und um es deutlich zu betonen -
Sie brauchen zwingend ein solches JsUnit-Framework, um die Tests auch wirk-
lich ausführen zu können! Es geht nicht darum, dass Sie in Ihrem Entwicklungs-
zyklus irgendwelche Tests manuell durchführen (was Sie natürlich auch machen
können).
Ein typischer Zyklus bei der testgetriebenen Entwicklung ist immer gleich. Die Unit-Tests
selbst und mit ihnen getestete Einheiten werden bei einer konsequenten TDD stets parallel
entwickelt. Die eigentliche Programmierung der Tests sowie Units erfolgt in kleinen und
sich immer wieder wiederholenden Schritten, die aus drei bzw. vier (je nach Zählweise)
Hauptteilen bestehen:
1. Zuerst schreibt man die Tests, die das erwünschte fehlerfreie Verhalten für eine be-
stimmte Funktionalität prüfen. Zu dem Zeitpunkt werden diese Tests von dem bestehen-
den Programmcode normalerweise noch nicht erfüllt bzw. es gibt diesen Programmcode
sogar noch gar nicht.
2. Der nächste Schritt ist das Ändern oder Erstellen des Programmcodes, der die Tests
erfüllen soll. Dabei sollte man diesen Code zu dem Zeitpunkt mit möglichst wenig Auf-
wand erstellen. Der Code braucht nicht optimiert zu sein. Ziel in dieser Phase ist nur,
dass der anschließende Testdurchlauf alle Tests besteht. Grundsätzlich ist die Philoso-
phie von TDD darauf ausgelegt, Tests zu bestehen, nicht eine konkrete Sotware zu erstel-
len. Die Erstellung der Sotware ist quasi ein „Nebenprodukt“.
3. Wenn die Tests bestanden sind, erfolgt die (vorsichtige) Optimierung des Codes ohne
Änderung der Funktionalität. Dies bezeichnet man als Refactoring (deutsch Refaktori-
sierung, Restrukturierung oder Umgestaltung). Diese manuelle oder automatisierte
Strukturverbesserung von Programmquelltexten soll die Lesbarkeit, Verständlichkeit,
Wartbarkeit und Erweiterbarkeit (und unter Umständen auch die Qualität, Stabilität und
Performance des Programms) verbessern.
4. Mit einem abschließenden Testen wird überprüt, ob die Refaktorisierung keine (uner-
wünschte) Veränderung des Programmverhaltens bewirkt hat.
Diese Schritte werden beim Vorantreiben der Applikation für jeden neuen Bestandteil der
Applikation so lange wiederholt, bis die gewünschte Funktionalität der ganzen Applikation
erreicht oder ein bekanntes Fehlverhalten bereinigt ist.