© Liashko/Shutterstock.com
Entwickler Magazin
Best Practices für TDD

So gelingt Test-driven Development

Wenn sich das Management entscheidet, Test-driven Development (TDD) einzuführen, ist das Ziel klar: neue Softwaresysteme innerhalb kürzester Zeit bei hoher Qualität ausliefern. Doch was oft gut startet, bekommt nicht selten schnell Ermüdungserscheinungen. Dieser Artikel zeigt, wie TDD nicht an Schwung verliert.

Sebastian Bindick


Die Idee von Test-driven Development ist nicht neu, aber heute aktueller denn je. Bereits 2002 stellte Kent Beck das Konzept des testgetriebenen Entwickelns vor. Mike Cohn lieferte 2010 fünf Gründe, weshalb aus seiner Sicht das Testen im Nachgang nicht funktioniert: Erstens gibt es im Nachhinein keine Möglichkeit, die Qualität eines Produkts zu verbessern. Zweitens bleiben manche Fehler unentdeckt und passieren deshalb immer wieder. Drittens lässt sich der Projektstatus nur schwer messen, klar ist lediglich der Stand der Featureumsetzung. Welche Qualität diese hat oder wie aufwendig die Fehlerabstellung ist, bleibt hingegen im Dunkeln. Schließlich kann viertens das Entwicklerteam nicht von Feedbackschleifen profitieren und bleiben fünftens nachgelagerte Tests aus Zeitgründen häufig auf der Strecke.

Viel effizienter ist da das kontinuierliche Testen der Applikation. Die Qualitätskontrolle wird damit fester Bestandteil des Entwicklungsprozesses, was u. a. zur Folge hat, dass der Testaufwand über die gesamte Projektlaufzeit gleichbleibt. Ein wichtiger Aspekt ist dabei die Verteilung der automatisierten Tests auf die richtigen Ebenen. Cohn beschreibt dafür eine Testpyramide. Den größten Anteil machen demnach die Modultests oder Unit-Tests aus, während der kleinste Teil aus automatisierten Integrations- und Oberflächentests besteht. Die Zahl der zu entwickelnden Tests nimmt also zur Spitze der Pyramide hin ab, während Komplexität, Ausführungsgeschwindigkeit und Kosten zunehmen.

Bei TDD schreiben die Entwickler erst den Test für eine Funktionalität und dann den eigentlichen Produktivcode. Das inkrementelle Vorgehen aus kleinen, nur wenige Minuten dauernden Tests und der Implementierung des Codes sorgt dafür, dass Testen und Entwickeln eng miteinander verzahnt sind. Auf den Test folgt das Schreiben des Produktivcodes und das Code Refactoring. Diese Vorgehensweise bleibt zwar immer gleich, damit TDD zum Erfolg wird, lohnt es sich aber, einige Punkte im Blick zu haben.

Organisatorische Faktoren

Das Entwicklerteam sollte von Anfang an stark in den Betrieb der Software eingebunden sein. Das hat in den meisten Fällen den positiven Aspekt, dass sich die Developer deutlich mehr für die Qualität des gelieferten Produkts einsetzen und offen für die Einführung von TDD sind. In regelmäßigen Runden zum Erfahrungsaustausch kann das Team Herausforderungen diskutieren und die Qualität der Tests analysieren. Das bewirkt eine kontinuierliche Sensibilisierung für das Thema und fü...

Entwickler Magazin
Best Practices für TDD

So gelingt Test-driven Development

Wenn sich das Management entscheidet, Test-driven Development (TDD) einzuführen, ist das Ziel klar: neue Softwaresysteme innerhalb kürzester Zeit bei hoher Qualität ausliefern. Doch was oft gut startet, bekommt nicht selten schnell Ermüdungserscheinungen. Dieser Artikel zeigt, wie TDD nicht an Schwung verliert.

Sebastian Bindick


Die Idee von Test-driven Development ist nicht neu, aber heute aktueller denn je. Bereits 2002 stellte Kent Beck das Konzept des testgetriebenen Entwickelns vor. Mike Cohn lieferte 2010 fünf Gründe, weshalb aus seiner Sicht das Testen im Nachgang nicht funktioniert: Erstens gibt es im Nachhinein keine Möglichkeit, die Qualität eines Produkts zu verbessern. Zweitens bleiben manche Fehler unentdeckt und passieren deshalb immer wieder. Drittens lässt sich der Projektstatus nur schwer messen, klar ist lediglich der Stand der Featureumsetzung. Welche Qualität diese hat oder wie aufwendig die Fehlerabstellung ist, bleibt hingegen im Dunkeln. Schließlich kann viertens das Entwicklerteam nicht von Feedbackschleifen profitieren und bleiben fünftens nachgelagerte Tests aus Zeitgründen häufig auf der Strecke.

Viel effizienter ist da das kontinuierliche Testen der Applikation. Die Qualitätskontrolle wird damit fester Bestandteil des Entwicklungsprozesses, was u. a. zur Folge hat, dass der Testaufwand über die gesamte Projektlaufzeit gleichbleibt. Ein wichtiger Aspekt ist dabei die Verteilung der automatisierten Tests auf die richtigen Ebenen. Cohn beschreibt dafür eine Testpyramide. Den größten Anteil machen demnach die Modultests oder Unit-Tests aus, während der kleinste Teil aus automatisierten Integrations- und Oberflächentests besteht. Die Zahl der zu entwickelnden Tests nimmt also zur Spitze der Pyramide hin ab, während Komplexität, Ausführungsgeschwindigkeit und Kosten zunehmen.

Bei TDD schreiben die Entwickler erst den Test für eine Funktionalität und dann den eigentlichen Produktivcode. Das inkrementelle Vorgehen aus kleinen, nur wenige Minuten dauernden Tests und der Implementierung des Codes sorgt dafür, dass Testen und Entwickeln eng miteinander verzahnt sind. Auf den Test folgt das Schreiben des Produktivcodes und das Code Refactoring. Diese Vorgehensweise bleibt zwar immer gleich, damit TDD zum Erfolg wird, lohnt es sich aber, einige Punkte im Blick zu haben.

Organisatorische Faktoren

Das Entwicklerteam sollte von Anfang an stark in den Betrieb der Software eingebunden sein. Das hat in den meisten Fällen den positiven Aspekt, dass sich die Developer deutlich mehr für die Qualität des gelieferten Produkts einsetzen und offen für die Einführung von TDD sind. In regelmäßigen Runden zum Erfahrungsaustausch kann das Team Herausforderungen diskutieren und die Qualität der Tests analysieren. Das bewirkt eine kontinuierliche Sensibilisierung für das Thema und fü...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang