Wie Projekte mit TDD starten? So geht’s!

by Gregor Biswanger 6. Mai 2010 18:31

Angeregt zu einem verzweifelten Blog-Post von Christina mit „Coding Dojo – aber wie?“, mit der großen Frage: „Wie soll eine mit TDD entwickelte Anwendung entstehen?“, wird dieser Artikel den Einstieg von „Projekte mit TDD starten“ erläutern. Dazu hat Christina noch folgende Fragen gestellt: „Vom Anfang an mit der Tastatur unter den Fingern oder darf es etwas Planung in den Köpfen und auf Papier stattfinden?“.

 

Das Problem im Detail

Doch „wie“ kann sich so eine Frage auf TDD beziehen? Wieso kristallisiert sich hierbei nicht vorerst die Frage: „Wie beginne ich ein Softwareprojekt?“. Ich sehe das als ein verständliches Problem, denn TDD gibt dem Entwickler gewisse beeinflussende Gefühle von Hilfestellung des Architekturdesigns.

Bei TDD wird von Beginn an eine spätere Sichtweise zur Handhabung der jeweiligen Komponente gewährleistet. Dabei entstehen hochwertige Komponenten, die sich auf deren Anforderungen zur späteren Weiterverwendung lohnen, indem zuerst von der äußeren Sichtweise der Komponenten begonnen wird. Genau so, wie sie eben später verwendet werden sollen. Doch leider hat das nichts mit einer automatischen Anforderungsanalyse zu tun.

Allerdings ist dieses häufige Missverständnis absolut verständlich. Denn TDD hilft genauso fehlende Anforderungen zu finden, indem bestimmte Schwierigkeiten auftreten, die vorerst nicht bedacht wurden. So entstehen dabei neue Anforderungen, oder anders ausgedrückt, sie ergänzen vorhandene Anforderungen.

Als Beispiel soll eine PLZ-Komponente für ein besseres Verständnis dienen. Diese Komponente verwendete ich gleichermaßen auch auf meiner TDD-Roadshow, die ich gemeinsam mit Robert Walter seit 2009 quer durch Deutschland vortrage. Hierbei hatten wir eine klare Anforderung als Ziel. Es soll die PLZ von meinem Heimatort Ingolstadt geliefert werden. Doch schlug bereits nach der fertigen Implementierung der Test fehl! Listing 1 demonstriert meinen ersten Testaufbau.

   1: [Test]
   2: public void Plz_from_Ingolstadt()
   3: {
   4:     // Arrange
   5:     IPlzReader plzReader = new PlzReader();
   6:  
   7:     // Act
   8:     string result = plzReader.GetPlzFrom("Ingolstadt");
   9:  
  10:     // Assert
  11:     Assert.AreEqual("85055", result);
  12: }

Listing 1 – Erwartet wird die PLZ von Ingolstadt

Dabei wurde selbstverständlich die PLZ verwendet, die ich durch meine Adresse gewohnt war. Also die Anforderung stand sicher fest. Ich erwarte ein Ergebnis das mir vorher bewusst war. Dennoch ist ein Fehler aufgetreten. Was habe ich übersehen? Woran habe ich nicht gedacht?

unit-test-fail

Abb.1. – Unit-Test schlieg fehl

Eine kleine Analyse des Fehlers zeigte mir, dass ich in jenem Augenblick nicht daran gedacht hatte, dass bei Städten auch mehrere PLZ Ergebnisse zurückkommen. Mit einem kurzen Grinsen und Kopfschütteln folgte auch ein: „Achja, ist doch klar! Weshalb habe ich nicht gleich daran gedacht?!“.

Aber meist liegt ja gerade an den einfachsten Dingen das große Problem. Ob es nun an meiner Intelligenz lag, mag ich bezweifeln, denn es ist „unmöglich“ an alles zu denken. So wie ein Testen auf alle je auftretenden Problemsituationen auch „unmöglich“ ist. Allerdings half mir dafür TDD weiter, indem mir eine fehlende Anforderung bewusst wurde. Ich musste anstatt eines einfachen String-Wertes ein String-Array von Ergebnissen erwarten.

Also Fakt ist, das TDD bei fehlenden Anforderungen weiterhilft. Dennoch dient TDD nicht zur Anforderungsanalyse für ein Softwareprojekt. Weil die hauptsächliche Anforderung „das erwarten meiner PLZ“ bereits bestand. TDD gibt einfach nur Hilfestellung, wenn zu der bereits stehenden Anforderung noch etwas vergessen wurde.

Darum wird eine Lösung benötigt, die vor TDD stattfinden muss, sodass die Frage doch eher lauten sollte: „Wie beginne ich ein Softwareprojekt?“. Wie dann mit TDD weiter gemacht wird, beantwortet sich dann ganz von selbst.

 

Die Lösung: Wie beginne ich ein Softwareprojekt?

Zu diesem Thema gibt es bereits zahlreiche Bücher, die jeden einzelnen Schritt bis ins Detail erklären. Ich möchte mich jedoch recht an der Oberfläche halten, so dass ein Gesamtbild zum Einstieg von TDD hilft.

 

Die Vision

Bevor es zur Konzeption des Projektes geht, spielt vorerst die Vision eine große Rolle. In den meisten Fällen erhalten wir einen Kunden, der eine großartige Idee für eine spätere Anwendung hat. Er hat viele, sogar sehr viele Bilder im Kopf, was er von seiner späteren Software erwartet.

Nun geht es darum, dass der Softwareentwickler gemeinsam mit dem Kunden über seine Wünsche spricht. Die schwierige Herausforderung in der Software-Branche ist, dass die Wünsche berufsspezifisch sind. Wird eine Software für einen Vermarkter entwickelt, müssen Grundkenntnisse in dessen Bereich aufgebaut werden.

 

Eine „Common Language“ aufbauen

Doch hierbei folgt schon das erste Problem: Kommunikation! Der Kunde ist Business-Experte in seinem Bereich und der Softwareentwickler ist der Business-Experte bei der Entwicklung von Software. Genauso wenig wie der Kunde sich für unseren Entwicklungsbereich interessiert, möchte der Entwickler so wenig wie möglich dessen Bereich lernen - nur so viel wie es nötig ist, um die Wünsche des Kunden zu befriedigen.

DieCommonLanguage

Abb.2. – Die Common Language

Für dieses Problem, gibt es nur eine Lösung. Es muss mit dem Kunden eine gemeinsame Sprache gefunden werden. Ich bezeichne es als die „Common Language“. Bei der Abb.2. zeigt die Grafik, dass es nur einen Weg gibt, wo der Kunde und der Entwickler auf eine gemeinsame Sprache stoßen. Diese beiden Welten treffen sich ausschließlich auf dem Bildschirm. Nachdem der Kunde seine Anforderungen gestellt hat, sollen dessen wünsche als Sketch (Zeichnung) festgehalten werden.

sketch

Abb.3. – Ein Sketch der Vision

Ist der Sketch abgesegnet worden, beginnen nun zwei weitere Prozesse. Der erste Prozess beginnt mit einer Abstraktion. Der Entwickler schaut sich in der Zeichnung alle Anwendungsfälle an und schreibt sie als User-Story auf. In der Regel sollte „eigentlich“ der Kunde diese User-Stories schreiben, allerdings zeigt die praktische Erfahrung dass es in den meisten Fällen besser ist, wenn die Entwickler diese selbst oder gemeinsam mit dem Kunden anfertigt. Der zweite Prozess beginnt nun beim Screen-Designer (falls vorhanden). Er baut aus dem Sketch einen Prototyp, zum Beispiel mittels Microsoft SketchFlow. Dabei wird auf die richtige Usability geachtet. Auf bestimmte Verhaltensmuster, die sichergestellt werden müssen, und ob der Kunde das auch so erwartet hat. Also gilt seine Vision vorerst spürbar zu Verfügung zu stellen.

sketchflow-prototype

Abb.4. – Ein SketchFlow-Prototype

 

Abstraktion der Anforderungen

Nun konnte durch die „Common Language“ die Anforderungen sichergestellt werden. Diese liegen nun als einfache User-Stories parat. Das Schreiben von User-Stories verlangt allerdings eine Art Disziplin. Sie sollten in der Sprache des Kunden liegen. Daher sollen technische Aspekte auf keinen Fall enthalten sein. Genau aus diesem Grund, sollte auch der Kunde „eigentlich“ selbst die User-Stories schreiben.

Softwarearchitektur-Abstraktionspyramide

Abb.5. – Die Abstraktionspyramide

Ein Beispiel als User-Story: „Bei der Eingabe eines Orts erhalte ich die jeweilige PLZ.“

Nun hat der Kunde seinen Prototyp erhalten und kann mittels SketchFlow-Player direkt Feedback an den Designer abgeben. Parallel zur gleichen Zeit, wird der Entwickler mit der Abstraktion der Anwendungsfälle (User-Stories) zu einzelnen Tasks beginnen. Diese Tasks beschreiben die benötigten Schritte um die Anforderung zu erfüllen.

Als Beispiel sind hier die Tasks zur oben angezeigten User-Story gelistet:

1: „Repository zur DB Abfrage für die PLZ coden“.

2: „Repository mittels Web-Service zur Verfügung stellen“.

3: „Web-Service Abfrage Client-seitig entwickeln“.

4: „PLZ-UserControl designen“.

5: „Design mit Code koppeln (MVVM)“.

Schnell wird ersichtlich, dass aus einer einfachen Anforderung viele Tasks entstehen.

Ziel erreicht! Ready to go for TDD!

Jetzt ist der Punkt erreicht, wo es klare Vorgaben durch Tasks gibt. Diese können nun mit TDD begonnen werden. Meist bildet man Tests genau nach den Softwareprozess mittels BDD (Behavior-Driven Development) ab. Das behilft gleichermaßen das Auffinden von unbedachten Anwendungsfällen.

 

Fazit

TDD ist ein mächtiges Werkzeug. Allerdings eben nur ein Werkzeug, das zu bestehenden Wünschen (Anforderungen) eingesetzt werden kann. Dass dazu Anforderungen vorerst nötig sind, wusste Christina laut ihres Blog-Posts bereits. Dennoch müssen diese Anforderungen mittels Abstraktion in einzelne Tasks gegliedert werden. Der Rest löst sich dann mit TDD meist von selbst. Wenn irgendwo eine Unsicherheit zur Umsetzung besteht, soll vorerst ein einfacher experimenteller Prototyp geschrieben werden. Ich hoffe ihr und anderen Lesern geholfen zu haben. Ready to go for TDD!



Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Powered by BlogEngine.NET 1.4.5.0
Theme by Extensive SEO

Über den Autor

Gregor Biswanger

Microsoft MVP für Client App Dev
XING

Gregor Biswanger (Microsoft MVP für Client App Dev) ist freier Consultant, Trainer, Autor und Speaker.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, agilen Prozessen und XAML. Er veröffentlichte vor kurzem seine DVD´s mit Video-Trainings zum Thema „Meine erste Windows 8 App“, „Windows Store Apps mit XAML und C#“ und „WPF 4.5 und Silverlight 5“ bei Addison-Wesley von video2brain.


Biswanger ist auch im Auftrag von Intel GmbH als Technologieberater für die Intel Developer Zone aktiv und ist Leader bei der Ingolstädter .NET Developers Group (INdotNET). 

 

Video über mich:
http://www.youtube.com/watch?v=mx_6SiiLxjk


Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)