Dienstag, 3. April 2007

Testen und Entwickeln

Sowohl bei der Arbeit als auch bei meinen privaten Entwicklungen bemerke ich, wie wichtig das testgetriebene Entwickeln ist. Wenn es irgendein "Paradigma" gibt, für das ich sofort zu missionieren bereit wäre, dann ist es die testgetriebene Entwicklung. Alles andere, Dinge wie SOA oder Web 2.0 eingeschlossen, sind im Vergleich zur testgetriebenen Entwicklung nichts weiter als Moden. Sie werden in zwei Jahren durch andere Moden ersetzt sein. Wenn sich aber im Bereich der testgetriebenen Entwicklung etwas tut, wird der gesamte Vorgang der Software-Entwicklung einen anderen Charakter haben als in den vergangen dreissig Jahren!

Die testgetriebene Entwicklung stellt die einzigartige Chance dar, die Softwareentwicklung endlich von dem Mief der Basteleien und Wurschteleien zu befreien, der ihr seit Anbeginn anhaftet. Sie hat das Potential für drastisch verkürzte Entwicklungszeiten, wie auch für schnelle Erweiterbarkeit und Änderbarkeit bestehender Software. Man darf endlich den Mut haben zu kontinuierlichen Programmverbesserungen, vor allem zu Vereinfachungen, zu Redesigns, Korrekturen und Erweiterungen. Endlich kann man es schaffen, einerseits den Quellcode stets so übersichtlich wie möglich zu halten und andererseits stets gerüstet und optimal angepasst an die aktuellen Anforderungen zu sein - und diese Anforderungen wechseln nun einmal ständig, so ist das Leben; die Herausforderung für die Entwicklung ist ja, stets für Änderungswünsche parat zu sein!

Für die Entwicklung ist es das A und O, dass es einen Button "Teste alles" gibt, wie in JUnit, ABAP Unit, ECMA Unit etc. Wenn alles OK ist, bekommt man während des Entwickelns eine kurze, unaufdringliche Success-Meldung in der Statuszeile. Nur wenn ein Test fehlschlägt, bekommt man das Protokoll zu sehen, mit einer möglichst präzisen Fehlermeldung, an welcher Stelle es nun nach meinen letzten Softwareänderungen haperte. Während des Entwickelns ebenso wie nach Eingang von Fehlermeldungen durch die Anwender erweitert man die Testsuite um neue Testfälle. Es entstehen also zwei Dinge: Der eigentliche Code und, parallel dazu, eine Sammlung von Testfällen, die die Funktionalität dieses Codes nachweist.

Aber die testgetriebene Entwicklung ist nicht nur eine Tool-, sondern auch eine Stilfrage. Es gehören auch Änderungen in den Programmiergewohnheiten dazu.
  • Es ist nützlich, bei neuen Entwicklungen zunächst einen leeren, lauffähigen Rahmen herzustellen. Dieser kann dann schrittweise um die gewünschten Funktionen ergänzt werden (inkrementeller Programmierstil).
  • Dabei fängt man sinnvollerweise zunächst mit der Benutzerschnittstelle (UI) an. Wenn die Bilder der Anwendung fertig sind, kann man sich der Navigation widmen, den Übergängen zwischen diesen Bildern, z.B. bei Betätigung eines Links oder Druck eines Buttons. Attribute und Methoden, die in die Anwendungslogik gehören, sieht man bereits in geeigneten Modelklassen vor, implementiert die Logik aber erst nach Fertigstellung von UI und Navigation.
  • Ständige Feedbacksitzungen mit dem Auftraggeber halten die Entwicklung auf Kurs. Sie helfen auch Missverständnisse vermeiden und ermöglichen ein frühes Testen. Je früher getestet werden kann und je häufiger derartige Runden stattfinden, desto geringer werden die Aufwände für die Gesamtentwicklung.
  • Auch der Entwicklungsauftrag passt sich während der Entwicklung an. Manche Anforderungen werden erst bemerkt, wenn ein erster Prototyp der Anwendung besichtigt werden kann. Vieles, was heute als Fehler gemeldet wird, basiert auf einem Missverständnis des Entwicklungsauftrags durch den Entwickler oder auf einer nicht erkannten, aber essentiellen Anforderung von seiten des Auftraggebers. Beides wird durch kurze Test- und Feedbackzyklen während des Entwickelns verhindert.

Wenn diese Art des Entwickelns zu unserer selbstverständlichen Gewohnheit wird, kommt dies einer Revolution in der Geschichte der Programmierkunst gleich!

Test It! :-)

Keine Kommentare :