Liebe Leserin, lieber Leser,
sagen wir, wie es ist: Getestet wird ungern, selbst in Zeiten agiler Entwicklung, deren Herzstück das agile Testing ist. Doch gerade, wenn die Anwendungen immer komplexer und größer werden, egal ob Web-, Client-, Mobile- oder Serversoftware, führt kein Weg an kontinuierlichen Tests vorbei. Also schreibt man ein Stück Software und überprüft, ob es auch wirklich funktioniert – und fertig, richtig? Leider sieht es in der Realität dann doch ein wenig komplizierter aus. Denn allein die Ziele von Softwaretests sind vielseitig: So kann es etwa darum gehen, die Ursache für einen bestimmten Fehler aufzufinden, oder man will beweisen, dass ein neu kreiertes System einwandfrei funktioniert. Oder aber man steht vor der Entwicklung einer neuen Software und will über Tests bereits im Vorfeld abklären, dass die Erwartungshaltung an den Code erfüllt wird. So oder so gilt: Je nachdem, welche Zwecke man verfolgt, gibt es unterschiedliche Arten zu testen.
Unit-Tests – erst Testen, dann programmieren!
Gerade bei agilen Softwareprojekten gehört die Implementierung von so genannten Unit-Tests mittlerweile zum Handwerkszeug. Mit Unit-Tests lässt sich das Verhalten einer Komponente isoliert, d. h. ohne ihre Abhängigkeiten zu anderen Komponenten, überprüfen. Infolgedessen erhält man bei dieser Testart direkt jede Menge kleinerer Tests, die jeweils nur das Verhalten einer ganz bestimmten Komponente prüfen. Der ein oder andere von Ihnen dürfte dieses Verfahren bereits angewandt haben und aus der Erfahrung wissen: Je näher die Deadline rückt, desto mehr werden Unit-Tests vernachlässigt. Eine gute Möglichkeit, diesem Problem entgegenzuwirken, ist es, die Tests zuerst zu schreiben und dann zu programmieren. Der Vorteil dieses Test-First-Ansatzes ist, dass die Software automatisch testbar ist, was die Fehlerfindung erheblich erleichtern und beschleunigen kann.
Allerdings gibt es auch einige Vorbehalte gegenüber Test First, die nicht von der Hand zu weisen sind. Realistisch betrachtet wird man für Unit-Tests etwa genauso viel Quellcode wie für die eigentliche Funktionalität schreiben. Und natürlich kann die Implementierung etwas länger dauern, wenn man neben der Funktion auch noch Unit-Tests schreibt. Auf lange Sicht zahlt sich der höhere Implementierungsaufwand jedoch bestenfalls durch niedrigere Wartungskosten aus. Wer jahrelang auf die Programmierung der „alten Schule“ gesetzt hat, dürfte zudem feststellen, dass es gar nicht mal so leicht ist, gute Unit-Tests zu schreiben. Das erfordert ein Umdenken, das natürlich nicht von heute auf morgen erledigt ist. Das Schwierigste ist aber wie immer der Anfang, und dabei wollen wir Sie in dieser Ausgabe unterstützen: Eine kleine Einführung (u. a.) zum Thema Test-First-Entwicklung gibt Oliver Sturm gleich zum Einstieg in seiner neuen Kolumne (S. 9). Wie die testgetriebene Entwicklung in der Praxis abläuft, zeigt Thomas Claudius Huber in seinem Artikel „ViewModels testgetrieben entwickeln“ (S. 14). Wer es bisher nicht versucht hat: Rein in den Sattel und einfach mal ausprobieren! Und nicht vergessen: Nur testbarer Code ist guter Code!
Scarlett Winter, Redakteurin
