Home > Softwareentwicklung > TDD – ein Garant für heiße Diskussionen

TDD – ein Garant für heiße Diskussionen

March 28th, 2010 Bernd

tdd

Beim allmonatlichen Treffen der .NET User Group Franken hatten wir am 25.03.2010 einen interaktiven Vortrag zum Thema Test Driven Development (TDD). Interaktiv deshalb, weil die Vortragenden Jürgen Laude und Jan Welker an einem praktischen Beispiel mit Live Coding gezeigt haben, wie TDD funktioniert. Dabei handelte es sich nicht um ein konstruiertes Beispiel, sondern um ein Problem, welches Jan vor ein paar Jahren schon einmal in einem Projekt gelöst hatte. Es wurde ein spezieller Parser für RSS Feeds entwickelt, die nicht standardkonform aufgebaut sind.

Schon die Anzahl der Gäste an diesem Abend (mit knapp 40 Teilnehmern war der Raum prall gefüllt) hat gezeigt, dass das Thema Testen und testgetriebene Entwicklung viele Softwareentwickler umtreibt. Dementsprechend zahlreich und kontrovers waren auch die Fragen und Diskussionen an dem Abend. Ich möchte hier zu ein paar der diskutierten Punkten meinen Kommentar abgeben.

TDD dient nicht dazu Fehler zu finden

Ein Punkt, der auch von den Referenten angesprochen wurde ist, dass mit TDD nicht in erster Linie Fehler gefunden, sondern verhindert werden sollen. Dadurch, dass die Tests vor dem zu testenden Produktionscode geschrieben werden, ist man gezwungen, testbaren, modularen und lose gekoppelten Code zu schreiben. TDD ist also das Werkzeug des Entwicklers für gutes Design. Hat man sich dieses Sicherheitsnetz aus Unit Tests geschaffen, kann man viel furchtloser mit dem Code arbeiten. Während der ständigen Refaktorierungen, die bei TDD üblich sind, wird man sofort auf Fehler hingewiesen, die man eventuell eingebaut hat. Auch wird sichergestellt, dass sich beim Implementieren neuer Features keine Fehler in die bereits bestehende Funktionalität eingeschlichen haben.

Sollten Internas einer Klasse getestet werden?

Meine Vermutung ist, dass diese Frage hauptsächlich von Leuten aufgeworfen wird, die den Code nicht testgetrieben entwickelt haben. Wenn Unittests im Nachhinein geschrieben werden, schleichen sich Zweifel ein, ob auch wirklich alles getestet ist und ob nicht doch was vergessen wurde. Lieber eine Methode zuviel als zuwenig getestet. Bei testgetriebener Entwicklung wird gegen das öffentliche Interface getestet. Die privaten Methoden entwickeln sich während der Refaktorierungschritte. Es wird damit zu jedem Zeitpunkt sichergestellt, dass die privaten Methoden implizit über das öffentliche Interface mitgetestet werden. Wenn man den Drang verspürt eine private Methode testen zu wollen, ist das ein Code Smell der auf eine Umstrukturierung der Klasse hindeutet.

Unittests können Integrations-, Akzeptanz- oder Systemtests nicht ersetzen

Wenn im Zuge von TDD erstellte Unittests keine Fehler finden, müssen diese Fehler natürlich durch andere Tests gefunden werden. Hier können Integrationstests (die durchaus auch mit einem Unittest Framework geschrieben werden können) und natürlich auch Systemtests helfen. Wenn die Projektstruktur es zulässt, können auch Akzeptanztests (z.B. mit FitNesse) erstellt werden, die es leichter machen direkt mit dem Kunden zu kommunizieren. Bei Akzeptanztests werden die Tests in einer Sprache beschrieben, die sowohl der Entwickler als auch der Kunde versteht.

Natürlich gibt es auch andere Meinungen zu dem Thema. René Drescher-Hackel hat z.B. auf seinem Blog den Post Gedanken zum Test Driven Development (TDD) veröffentlicht.

Es leuchtet ein, dass ein zweistündiges Event zum Thema TDD nicht alle Fragen beantworten und alle Zweifel ausräumen kann. Vielmehr ist es ein Denkanstoß und vielleicht ein Motivationsschub um die Ärmel hochzukrämpeln und TDD in eigenen Projekten anzuwenden und auszuprobieren.

Kick it on dotnet-kicks.de
Categories: Softwareentwicklung Tags:
Comments are closed.