ATDD in der Praxis: Eine praktische Einführung in die Akzeptanztest-getriebene Softwareentwicklung mit Cucumber, Selenium und FitNesse

Von Markus Gärtner

Diese Buch bietet eine praxisbezogene und anschauliche Einführung in die akzeptanztestgetriebene Entwicklung (Acceptance Test-driven Development, ATTD, auch bekannt als Behavior-driven Development oder Specification-by-Example). Anhand zweier ausführlicher Praxisbeispiele erfährt der Leser, wie sich Testautomatisierung innerhalb eines agilen Entwicklungsprozesses verwenden lässt. Anschließend werden die grundlegenden Prinzipien zusammengefasst und verdeutlicht. Dadurch erlebt der Leser praxisnah, was ATDD ist, und bekommt wertvolle Hinweise, wie er entsprechende Prozesse aufbauen kann.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 2. Apr. 2013
• ISBN: 9783864912726

Buchvorschau

1 Einleitung

In diesem Buch gebe ich eine Einführung für Einsteiger in das Verfahren, das als Akzeptanztest-getriebene Entwicklung (engl. Acceptance Test-Driven Development, kurz ATDD) bekannt wurde. Als ich 2008 das erste Mal mit dem Begriff ATDD konfrontiert wurde, wirkte es auf mich konstruiert und unnötig. Es erschien mir überflüssig, da ich ja 2008 schon die testgetriebene Entwicklung erlernt hatte und mir das völlig ausreichend vorkam. Und überhaupt, warum sollte ich auf Akzeptanzkriterien testen?

»O tempora, o mores«. Vier Jahre später schreibe ich nun selbst ein Buch über das, was man nun als Akzeptanztest-getriebene Entwicklung kennt. 2009 traf ich in London Gojko Adzic, der mir ein Exemplar seines Buchs Bridging the Communication Gap [Adz09] in die Hand drückte. Als ich es gleich auf der Heimreise zu Ende gelesen hatte, hatte ich eine Vorstellung von ATDD und wusste, warum man diesen Begriff meiden sollte.

Warum habe ich den Stoß Papier¹ in Ihren Händen dennoch ATDD in der Praxis genannt?

Über den Begriff

ATDD kennt man schon eine ganze Weile, aber nicht nur unter dieser einen Bezeichnung. Das gleiche Verfahren kennt man auch unter anderen Namen. Hier eine unvollständige Liste:

Akzeptanztest-getriebene Entwicklung

Verhaltensgetriebene Entwicklung (Behavior-Driven Development: BDD)

Specification-by-Example

Agile-Acceptance-Testing

Story-Testing

Meiner Ansicht nach hat jede dieser Bezeichnungen Nachteile. Die Bezeichnung »Akzeptanztest-getriebene Entwicklung« vermittelt die Vorstellung, dass wir mit der Iteration schon fertig wären, wenn nur der Akzeptanztest erfolgreich durchläuft. Das stimmt so nicht, da jede Konstellation von Tests nicht alles abdecken kann. Im Netz der Tests gibt es immer Lücken. In der Welt des Testens ist man sich immer bewusst, dass man nicht alles testen kann. Allerdings wissen wir, wie Michael Bolton es einmal formuliert hat, dass wir auf gar keinen Fall mit der Arbeit fertig sind, wenn ein Akzeptanztest fehlgeschlagen ist.

Statt nun hier über die verschiedenen Bezeichnungen zu diskutieren, habe ich beschlossen eine Auswahl möglicher Alternativen anzubieten, um den Leser entscheiden zu lassen, welche ihm am besten passt. Unter dem Strich ist es unerheblich, wie man es nennt, solange es funktioniert. Die Welt der Softwareentwicklung ist voll von missverständlichen Ausdrücken und das wird bestimmt auch noch einige Jahre so bleiben. Software-Engineering, Testautomatisierung und Testgetriebene Entwicklung sind alle auf die eine oder andere Weise irreführend. Wie bei jeder Abstraktion sollte man den Begriff nicht mit dem Gegenstand verwechseln. Die Experten wissen um die Begrenztheit der Begriffe dieser Ansätze.

Aber was ist, wenn es mehrere Bezeichnungen für einen ähnlichen Ansatz gibt? Die von Ihnen verwendeten Verfahren mögen sehr wohl davon abweichen. Nachdem ich nun schon mehrere Teams in verschiedenen Unternehmen aufgesucht und beraten habe, ist mir aufgefallen, dass sie alle eines gemeinsam hatten: Jedes unterschied sich vom anderen. Während die Vorgehensweise Ihres Teams in Ihrer momentanen Firma wunderbar funktioniert, kann sie in einer anderen drastisch fehlschlagen. Haben Sie sich jemals über die Antwort des Beraters gewundert, wenn er mal wieder sagt »kommt darauf an«? Darin liegt der Grund.

Im Rahmen seines Buchs Specification by Example [Adz11] hat Gojko Adzic über fünfzig Teams befragt, die ATDD in der einen oder anderen Form anwenden. Dabei fand er eine ganze Reihe unterschiedlicher Verfahren heraus, die den ATDD-Ansatz begleiten. Alle Teams, die ATDD erfolgreich anwenden, beginnen mit einem grundlegenden Ansatz, werfen nach einiger Zeit einen Blick darauf und passen ihn dann anhand der eigenen Bedürfnisse im jeweiligen Kontext an. Eine sehr agile Vorgehensweise bei der Erprobung eines Ansatzes ist, wenn Sie mit einem sehr leichtgewichtigen Prozess einsteigen und dann neue Dinge anpassen, sobald sich Probleme ergeben. Bei der Anwendung von ATDD sollten Sie nicht vergessen, dass Ihr erstes Bündel an Verfahren aller Wahrscheinlichkeit nach nicht alle Ihre Probleme löst. Mit der Zeit werden Sie den Lösungsweg anpassen, wobei Sie immer mehr Erfahrungen sammeln.

Warum noch ein Buch über ATDD?

Während Gojko schon viele Muster erfolgreicher ATDD-Implementierungen beschrieben hat, klafft meiner Meinung nach bis jetzt noch eine Riesenlücke in den Büchern über ATDD. Es gibt einen großen Unterschied zwischen fortgeschrittenen Anwendern einer Fertigkeit oder eines Ansatzes und dem Anfänger darin.

Als ich die Literatur über ATDD durchging, fand ich mehrere Bücher, die Fortgeschrittene ansprachen und ihnen ATDD durch Verweis auf erfolgreiche Anwendungen erklärten. Für diese Lesergruppe ist es relativ einfach, diese Beispiele auf ihr eigenes Umfeld zu übertragen. Für den Anfänger auf diesem Gebiet trifft das allerdings nicht zu. Der Anfänger braucht konkrete Anleitungen, damit er loslegen kann. Wenn jemand anhand der Grundlagen erst einmal Erfahrungen gesammelt hat, kann er oder sie sich langsam von den engen Begrenzungen der Methode lossagen.

Anfänger lernen am besten, indem sie ein Rezept befolgen, und doch ist dieses Buch kein Kochbuch zu ATDD. Durch die Beispiele in diesem Buch vermittle ich zwei funktionierende Wege zu ATDD und beschreibe die Überlegungen der beteiligten Personen. Der Anfänger kann dies nutzen, um mit dem Einsatz von ATDD in seinem Team einzusteigen. Im Verlauf gebe ich außerdem noch Hinweise auf weiterführende Literatur.

Die Grundidee dieses Buchs entspringt dem Buch Test-Driven Development by Example von Kent Beck. Auch Beck liefert zwei funktionierende Beispiele Testgetriebener Entwicklung und erklärt im Anschluss die zugrunde liegenden Prinzipien. Das Buch war als Einsteigerbeschreibung zu TDD gedacht und liefert dem Anfänger für die ersten Schritte ausreichend Material – davon ausgehend, dass TDD mittels Reflexion und Übung erlernbar ist. Das Gleiche gilt im gewissen Umfang auch für dieses Buch.

Fachbegriffe

In diesem Buch werde ich immer wieder Begriffe aus der Welt der Agilen Softwareentwicklung verwenden. Da sicher nicht jeder Leser mit der Agilen Softwareentwicklung vertraut ist, ist an dieser Stelle eine kurze Einführung in diese Begriffe nötig.

Product-Owner:

In der Agilen Methode Scrum werden drei Rollen festgelegt: das Entwicklerteam, der Scrum-Master und der Product-Owner. Der Product-Owner ist für den Erfolg des Produkts, das das Team herstellt, verantwortlich. Er oder sie setzt die Prioritäten für die Features, die das Team implementieren soll und arbeitet mit den Stakeholdern zusammen, um diese herauszuarbeiten. Er oder sie vertritt also den Kunden im Team und entscheidet in dieser Funktion auch über Details, die er mit den Stakeholdern verhandeln muss.

Iteration oder Sprint:

Die Agile Softwareentwicklung beruht auf einem regelmäßigen Zyklus, der Iteration, bei Scrum auch Sprint genannt. Während dieser kurzen Arbeitsphasen implementiert das Team eine neue Ausbaustufe des Produkts, das im Prinzip auslieferbar ist. Die üblichen Iterationsintervalle liegen zwischen einer und vier Wochen.

User-Story:

Die User-Story ist ein begrenzter Umfang von Funktionalität, von dem das Team den Eindruck hat, es könne innerhalb einer Iteration implementiert werden. Sie bezeichnet einen sehr kleinen Abschnitt des Produkts. Im Normalfall ist das Team bestrebt, mehrere dieser User-Stories innerhalb einer Iteration zu implementieren. Für die Festlegung der User-Stories ist der Kundenvertreter, respektive Product-Owner, verantwortlich.

Taskboard:

Die meisten mit Agilen Methoden arbeitenden Teams planen ihre Arbeit auf einer Tafel, die für jedermann sichtbar ist. Sie benutzen dazu Kärtchen, um anzuzeigen, woran sie gerade arbeiten. Das Taskboard hat in der Regel mehrere Spalten, zumindest ToDo (ToDo), In Arbeit (Doing) und Erledigt (Done). Im Verlauf der Arbeit werden die Fortschritte auf dem Taskboard aktualisiert.

Story-Card:

Die User-Stories werden normalerweise auf Kärtchen geschrieben, die während der Iteration auf dem Taskboard des Teams angebracht sind.

Standup-Meeting, Daily Scrum:

Mindestens täglich bringen sich die Mitglieder des Teams gegenseitig auf den neuesten Stand der Iteration. Das Team trifft sich dazu eine Viertelstunde lang und bespricht, wie es die zu erledigenden Aufgaben (Tasks) bis zum Ende der Iteration bewältigen kann.

Product-Backlog, Sprint-Backlog:

Bei Scrum organisiert der Product-Owner die noch nicht implementierten User-Stories in einem Product-Backlog. Er oder sie ist für die Aktualisierung des Backlogs verantwortlich, sobald neue Anforderungen an das Produkt eintreffen. Wenn sich das Team zur Planung des nächsten Sprints zusammensetzt, erstellt es für diesen einen eigenen Backlog – den Sprint-Backlog. Die dabei ausgewählten User-Stories werden automatisch Teil des Sprint-Backlogs. Der Sprint-Backlog wird nach dem Planungstreffen meistens auf dem Taskboard organisiert.

Refaktorisieren/Refactoring:

Mit dem Refaktorisieren oder Refactoring ist die Veränderung der Struktur des Codes gemeint, ohne dessen Funktion zu verändern. Meistens refaktorisiere ich den Code, bevor ich Änderungen einführe. Durch das Refaktorisieren erleichtere ich mir die Implementierungen der anstehenden Änderungen.

Testgetriebene Entwicklung (Test-Driven Development, TDD):

Bei der Testgetriebenen Entwicklung schreiben Sie einen einzelnen Test, der zunächst fehlschlägt; Sie schreiben dann gerade so viel Code, dass dieser fehlgeschlagene Test bestanden wird (und die bis dahin bestandenen Test es immer noch tun) und refaktorisieren anschließend Ihren Code, um ihn für den nächsten kleinen Schritt vorzubereiten. TDD bezeichnet einen Ansatz im Design und hilft seinen Nutzern beim Schreiben von besserem Code, da von Anfang an testbarer Code entsteht.

Continuous Integration (CI):

Bei Continuous Integration werden die Änderungen des Quellcodes in kurzen Abständen integriert. Ein Build-Server baut daraufhin den ganzen Entwicklungszweig (Branch), führt alle Unit- und Akzeptanztests aus und gibt die Informationen über diesen Build an alle Ihre Kollegen weiter. CI beruht auf einem automatisierten Build und erleichtert dem Team, Probleme im momentanen Zustand des Branches sehr früh zu erkennen – und nicht erst eine Stunde vor der Auslieferung des Releases.

Wie man dieses Buch am besten liest

In diesem Buch biete ich eine Mischung aus konkreten Verfahren neben einigen Prinzipien, die ich als nützlich erachte. Es gibt mehrere Möglichkeiten, dieses Buch zu lesen – je nach Kenntnisstand können Sie sich eine aussuchen.

Sie können das Buch direkt von vorne bis hinten lesen. Sie werden dabei einiges über Cucumber, Behavior-Driven-Development und das Testen von Webseiten mit einem ATDD-Tool erfahren. Das erste Beispiel beruht überdies auf einem Team, in dem zwischen Test- und Programmierexperten unterschieden wird. Sie werden feststellen, dass ein wesentlicher Erfolgsfaktor dieses Teams in dessen Zusammenarbeit zwischen den verschiedenen Experten liegt.

Im zweiten Teil werde ich mit Ihnen, lieber Leser, entwickeln. Indem wir Pair-Programming betreiben, können wir zu diesem Zeitpunkt evtl. vorhandene Wissenslücken beim Testen oder Programmieren ausgleichen. Wir werden unseren Anwendungscode mithilfe von ATDD auf praktische Weise vorantreiben. Wie werden uns mit FitNesse, einem Wiki-basierten Akzeptanztest-Framework befassen. Die Beispiele im zweiten Teil sind in Java geschrieben.

Im dritten Teil werden Sie die nötige Orientierung finden, um mit dem ATDD-Ansatz die ersten eigenen Schritte vornehmen zu können. Ich gebe Hinweise auf weiterführende Literatur sowie Tipps zum Einstieg. Außerdem erkläre ich, was sich bewährt hat und was bei anderen Teams nicht so gut geklappt hat.

Im Anhang finden Sie zwei Tools, die in diesem Buch zur Anwendung kamen und sogar noch ein Drittes, das Robot Framework, das in einiger Ausführlichkeit vorgestellt wird, damit Sie den richtigen Einstieg finden. Wenn Sie noch nichts mit Cucumber oder FitNesse zu tun hatten, beginnen Sie die Lektüre evtl. dort.

Als Fortgeschrittener könnten Sie die ersten beiden Teile zunächst überspringen und direkt in die konzeptuellen Erklärungen im dritten Teil einsteigen. Möglicherweise wollen Sie später Ihren Kollegen ein paar Hintergrundinformationen liefern. Die Beispiele in den Teilen I und II bieten sich dann dazu an.

Vielleicht wollen Sie aber auch die ersten beiden Beispiele studieren, um gleich selbst an die Arbeit zu gehen und eine einfache Implementierung zu starten. Wenn Sie nicht mehr weiterwissen, nehmen Sie das Buch wieder zur Hand und lesen Sie im dritten Teil mehr dazu – obwohl ich diese Lesereihenfolge nicht unbedingt empfehlen würde. Falls Sie bereits eine ATDD-Implementierung in Ihrem Team realisiert haben, wollen Sie sich vermutlich in Teil II vertiefen, wo ich erkläre, wie Sie den Domänen-Code von Ihren Beispielen treiben lassen.

Das waren einige der Möglichkeiten, wie man das Buch lesen könnte. Wenn Ihr Leseverhalten dem meinen ähnelt, dann erwägen Sie vermutlich, den Beispielen zu folgen und den bereitgestellten Code selbst zu implementieren. Für jedes der Codebeispiele habe ich ein GitHub-Repository erstellt. Auf diese Weise konnte ich die Beispiele selbst auf die Akzeptanzkriterien testen. Wenn Sie selbst nicht mehr weiter wissen, können Sie selbst dort hineinschauen. Sie finden die Beispiele des ersten Teils unter http://github.com/mgaertne/airport-de und die des zweiten unter http://github.com/mgaertne/trafficlights-de.

Danksagungen

Ein Projekt wie dieses Buch wäre ohne die Unterstützung vieler Helfer gar nicht möglich. Als Erstes möchte ich mich bei Dale Emery bedanken, der so viele gute Anmerkungen zu meinem Schreibstil beigetragen hat. Als Nichtmuttersprachler im Englischen habe ich das Feedback von Dale sehr begrüßt.

Ein besonderer Dank gilt Kent Beck. Im August 2010 wandte ich mich an ihn, weil ich ein Buch über ATDD verfassen wollte, das den gleichen Ansatz verfolgen sollte, den er in seinem Buch TDD by Example verwendet hatte. Er stellte mich auch bei Addison-Wesley vor und machte mich mit Christopher Guzikowski bekannt, der mir alle nötige Unterstützung bei der Veröffentlichung dieses Werkes gewährte.

Mehrere Leute haben mir Rückmeldungen nach Lektüre der ersten Entwürfe gegeben. Für dieses Feedback möchte ich mich bei Lisa Crispin, Matt Heusser, Elisabeth Hendrickson, Brett Schuchert, Gojko Adzic, George Dinwiddie, Kevin Bodie, Olaf Lewitz, Manuel Küblböck, Andreas Havenstein, Sebastian Sanitz, Meike Mertsch, Gregor Gramlich und Stephan Kämper bedanken.

Zu guter Letzt möchte ich mich bei meiner Frau Jennifer und unseren Kindern Katrin und Leon für ihre Unterstützung während der Entstehung dieses Buchs bedanken. Ich hoffe, dass ich die Zeit, die sie währenddessen ohne Mann oder Vater auskommen mussten, in den nächsten Jahren zurückgeben kann.

Teil I: Flughafenparkplatz

In diesem Teil des Buchs werden wir uns eine Webanwendung ansehen. Testautomatisierung über grafische Benutzeroberflächen gehört zu den Dingen, die heutzutage ganz gut funktionieren. Man hat zwar einige Nachteile in Kauf zu nehmen. Die meisten Teams, die sich mit Webanwendungen befassen, werden hier aber einige Tipps bekommen, wie sie ihre Tests trotzdem erfolgreich durchführen können.

Die Anwendung, die es zu erstellen gilt, ist ein Parkgebührenrechner für einen internationalen Flughafen. Es gibt an diesem Flughafen mehrere Parkplätze mit jeweils unterschiedlichen Gebühren für die Parkzeiträume.

Die zugrunde liegenden Gebührenordnungen für den Parkgebührenrechner sind derart kompliziert, dass das Team beim ersten Anlauf einer solchen Webanwendung gescheitert ist. Da die Mitglieder des Teams davon ausgehen, dass sie die Anforderungen falsch formuliert haben, möchten sie die Angelegenheit dieses Mal anders angehen. Die Anwendung soll nun im Rahmen eines Spezifikationsworkshops mit den Kunden erörtert werden. Das heißt, Tester, Programmierer und Kunden besprechen konkrete Beispiele, die für die Gebührenordnungen des Parkgebührenrechners stehen.

Parallel zu den Programmiertätigkeiten automatisiert der Tester diese Beispiele mithilfe von Cucumber und Ruby in Kombination mit Selenium. An einer bestimmten Stelle könnte er etwas Hilfe vom Programmierer brauchen, ... aber ich möchte in der Einleitung noch nicht zu viel verraten.

Für den Fall, dass Sie sich fragen, mit welchem Tool der Tester Thorsten die Cucumber-Beispiele editiert: Er arbeitet selbstverständlich mit emacs und nicht mit vi.

2 Workshop zum Parkgebührenrechner

Vor einiger Zeit hat die Flughafenbetreibergesellschaft Blaport AG beschlossen, ihren Internetauftritt zu erweitern. Vor allem sollen die potenziellen Reisenden, ihre Parkgebühren im Voraus ermitteln können. Zu diesem Zweck sollen sie ein Online-Formular ausfüllen können, das ihre Parkgebühren für die gewünschte Reisedauer berechnet.

Die Flughafengesellschaft hatte solch ein Formular zuvor auch schon verwendet. Allerdings waren die Rückmeldungen der Reisenden auf dieses Formular derart negativ, dass sich das Management dazu entschloss, es von Grund auf neu zu erstellen.

Aufgrund der Erfahrungen mit dem vorherigen Projekt wählt das Implementierungsteam, dem die leitende Programmiererin Petra, der Programmierer Alex und der Tester Thorsten angehören, einen anderen Ansatz. Bei der ersten Implementierung schienen sich die Anforderungen laufend zu ändern, so dass der Code mit jedem Patch anschwoll, was am Ende zu der Erkenntnis führte, dass man die falsche Sache implementiert hatte.

Statt diesen Prozess erneut zu durchlaufen, führt das Team jetzt einen Spezifikationsworkshop durch, um die Gebührenordnungen für den Parkgebührenrechner zusammenzutragen. Im Hinblick auf die neue Funktionalität haben Petra und Thorsten den Leiter der Blaport-Parkplatzverwaltung, Bernd, als Business-Experten für Parkgebühren eingeladen.

Valet-Parking

Petra: Alles klar, dann lassen Sie uns die Anforderungen für die Parkgebührenberechnung besprechen. Bernd, was können Sie uns zu diesem Thema sagen?

Bernd: Im Prinzip gibt es bei uns drei unterschiedliche Typen von Parkplätzen. Einige erheben ihre Gebühren stundenweise, einige pro Tag, wiederum andere haben ein Tages- oder Wochenlimit.

Petra: Wie nennen Sie denn diese verschiedenen Parkplätze? Gibt es da bestimmte Bezeichnungen?

Bernd: Valet-Parking, Kurzzeitparken und normales Parken. Falls Sie Ihren Parkschein verlieren, werden Ihnen 10,00 € berechnet.

Petra: Konzentrieren wir uns zunächst auf diese drei Typen. Worin bestehen die Unterschiede zwischen ihnen?

Bernd: »Valet-Parking« ist Parken mit einem Chauffeur. Man gibt das Auto beim Chauffeur ab, der parkt das für den Gast und holt es später für ihn ab.

Petra: Können Sie uns etwas über die Parkgebühren sagen?

Bernd: Das Valet-Parking kostet 18,00 € pro Tag. Beim Parken bis zu 5 Stunden bekommen Sie eine Ermäßigung von 6,00 €.

Thorsten: Moment mal, Bernd. Sie meinen also, dass ich selbst für nur 30 Minuten 12,00 € bezahlen muss, ebenso für drei Stunden, wie auch für fünf Stunden? Aber für