ATDD in der Praxis E-Book

Markus Gärtner

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2013

Seitenzahl: 280

Beschreibung

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.

Leseprobe

Markus Gärtner arbeitet als Agiler Tester, Trainer, Coach und Berater bei der it-agile GmbH in Hamburg. Er hat den German Agile Testing and Exploratory-Workshop (GATE) 2011 gegründet und ist Mitbegründer des europäischen Abschnitts von Weekend Testing. Außerdem ist er Schwarzgurt-Lehrmeister in der Miagi-Do-Schule des Softwaretestens und trägt zur Agile Alliance FTT-Patterns Writing Community sowie zur Software-Craftsmanship-Bewegung bei. Er referiert regelmäßig weltweit auf agilen und Tester-Konferenzen und widmet sich ausgiebig dem Schreiben über das Testen. Er bloggt regelmäßig auf Englisch unter www.shino.de/blog und auf Deutsch unter www.mgaertne.de. Er lehrt bei Kunden in der agilen Welt ATDD und kontextgetriebenes Testen. ATDD hat er Testern ohne technischen Hintergrund sowie Programmierern vermittelt.

ATDD in der Praxis

Eine praktische Einführung in dieAkzeptanztest-getriebene Softwareentwicklungmit Cucumber, Selenium und FitNesse

Markus Gärtner

Markus Gä[email protected]

Lektorat: René SchönfeldtÜbersetzung: Volker Haxsen, HeidelbergCopy Editing: Christoph Ecken, HeidelbergHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Buch 978-3-86490-046-4PDF 978-3-86491-271-9ePub 978-3-86491-272-6

1. Auflage 2013Copyright der Übersetzung © 2013 dpunkt.verlag GmbHRingstraße 19B69115 Heidelberg

Copyright © 2012 by Pearson Education, Inc.Title of the English original: ATDD by Example, ISBN 978-0321784155Translation Copyright © 2012 by dpunkt.verlag. All rights reserved.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Geleitwort von Kent Beck1

Es gibt eine auffällige Parallele in der Art, wie in diesem Buch die Akzeptanztestgetriebene Entwicklung präsentiert und wie Software mit ATDD entwickelt wird. Es ist eine Kunst, spezifische Beispiele für das Verhalten eines Programms auszuwählen, die geeignet sind, das korrekte Gesamtverhalten eines Systems zu beschreiben. Genauso ist es eine Kunst, bestimmte Beispiele für eine Programmiertechnik wie ATDD herauszufinden, die Ihnen, dem Leser, die Möglichkeit eröffnen, die Technik selbst zu erlernen. Markus sind sowohl die Auswahl als auch die Präsentation der Beispiele hervorragend gelungen.

Um dieses Buch mit Gewinn zu lesen, werden Sie auch Code lesen müssen. Dabei können Sie das Umdenken praktisch lernen, das nötig ist, um erfolgreich mit ATDD zu arbeiten. Das Umdenken besteht, kurz gesagt, darin, von »Dieses Feature hätte ich gerne« zum »Wie wollen wir das testen? Hier hätte ich ein Beispiel« zu gelangen. Bei der Lektüre der Beispiele werden Sie immer wieder feststellen, wie sich dieses Umdenken in verschiedenen Kontexten niederschlägt.

Was mir an dieser codezentrierten Darstellung so gefällt, ist, wie sie auf Ihre Lernfähigkeit setzt. Dies sind nicht einfach »12 einfache Regeln zum Testen Ihrer Webanwendung«, die auf intellektuell angehauchtes Seidenpapier gedruckt sind, sich aber beim ersten Kontakt mit der Realität auflösen. Hier werden Ihnen konkrete Entscheidungen präsentiert, die in konkreten Kontexten getroffen wurden. An diesen Entscheidungen sollen Sie sich reiben, Sie sollen über sie diskutieren, und Sie können dann zu eigenen Schlüssen kommen (und das werden Sie auch tun, wenn Sie das Maximum aus diesem Buch herausholen wollen).

In den letzten Teilen des Buches werden allgemeine Schlussfolgerungen gezogen und die den Beispielen zugrunde liegenden Prinzipien zusammengefasst. Wenn Sie also zu denen gehören, die besser lernen, wenn sie zuvor die allgemeinen Prinzipien verstanden haben, dann können Sie mit der Lektüre auch dort beginnen. Wie auch immer, der Gewinn aus diesem Buch hängt direkt von Ihrer Bereitschaft ab, den Beispielen zu folgen.

Eine der ursprünglich beschriebenen Schwächen von TDD ist, dass dieser Weg zu einer Programmiertechnik führt, die den Bedürfnissen des Programmierers dient. Einige Programmierer hingegen betrachten TDD etwas weiter gefasst und wechseln leicht zwischen den verschiedenen Abstraktionsgraden ihrer Tests. Bei ATDD gibt es diese Unklarheit nicht – sie ist eine Technik zur Verbesserung der Kommunikation mit Leuten, denen Programmiersprachen fremd sind. Die Qualität unserer Beziehungen und der Kommunikation, auf der diese beruhen, fördern die effektive Softwareentwicklung. ATDD kann einen bedeutenden Schritt in Richtung klarer Kommunikation sein und ATDD in der Praxis ist eine gründliche, verständliche Einführung.

Kent Beck

Geleitwort von Dale Emery1

Allzu oft erzielen Softwareprojekte nicht das, was der Kunde fordert. Mit den Jahren habe ich viele Projektkunden die Mängel so charakterisieren hören: »Die Entwickler hören nicht richtig hin, wenn wir ihnen sagen, was sie konstruieren sollen.« Und ebenso habe ich Hunderte von Entwicklern klagen hören: »Die Kunden sagen uns nicht, was sie wollen. Meistens wissen sie noch nicht einmal, was sie wollen.«

Ich habe genug Projekte beobachtet, um zu einem anderen Schluss zu kommen: Die Anforderungen an das Softwaresystem zu formulieren ist schwer. Es erfordert präzise Formulierungen und exaktes Zuhören, was in der menschlichen Kommunikation selten geworden ist – aber auch selten derart wichtig war. Gute Software zu schreiben ist schwer. Software zu testen ist ebenfalls schwer. Aber das Schwerste bei der Arbei an Software ist die klare Kommunikation über das, was wir von dem System erwarten.

Aktzeptanztest-getriebene Entwicklung (ATDD) hilft bei dieser Herausforderung. Bei ATDD arbeitet das ganze Team zusammen, um Klarheit und ein gemeinsames Verständnis zu gewinnen, bevor die eigentliche Entwicklung beginnt. Im Kern von ATDD gibt es zwei Hauptvorgehensweisen: Vor der Implementierung eines jeden Features finden sich die Teammitglieder zusammen, um konkrete Einsatzbeispiele für dieses Feature zu sammeln. Anschließend generiert das Team aus den Beispielen automatisierte Akzeptanztests. Diese Beispiele und Tests werden dann bei jedem Feature ein wesentlicher Teil der vom Team gemeinsam getragenen und präzisen Auffassung dessen, was als erledigt bzw. »done« erachtet werden soll.

Was ist dieses gemeinsame Wissen wert? Ein Teilnehmer eines ATDD-Workshops hat es einmal so formuliert: »Als wir erst einmal angefangen hatten, mit konkreten Beispielen zu arbeiten, hat mir unsere Arbeit etwas bedeutet. Ich hatte endlich verstanden, was wir da konstruieren und warum überhaupt. Und noch wichtiger, ich wusste, dass auch das ganze Team verstanden hatte, was wir erreichen wollten. Auf einmal hatten wir alle das gleiche Ziel – wir waren ein echtes Team geworden.«

ATDD sagt uns aber nicht nur, wann etwas erledigt ist, sondern auch, wie unser Arbeitsfortschritt aussieht. So, wie wir die Tests automatisieren und die Software schreiben, dass sie diese Tests (und alle vorigen) besteht, dienen uns diese Beispiele als Wegweiser auf dem Weg zur fertigen Software. Und da jedes dieser Beispiele für eine Aufgabe steht, die der Kunde schätzt, haben wir nicht nur das Gefühl Fortschritte gemacht zu haben, sondern auch solche Fortschritte, die wirklich zählen.

Ich habe jetzt einige Hauptaspekte und einige wesentliche Vorteile von ATDD aufgezählt. Das war der einfache Teil. Nun zum schwierigen Teil: Wie setzt man diese Dinge so um, dass sie in der Praxis funktionieren? Das überlasse ich Markus Gärtner. In seinem Buch ATDD in der Praxis krempelt Markus seine Ärmel hoch und erzählt Ihnen nicht nur von ATDD, sondern er zeigt Ihnen auch, wie es in der Praxis funktioniert. Er lässt Sie über die Schultern und in die Köpfe von Testern, Programmierern und Businessexperten schauen und verstehen, wie sie die Prinzipien und Verfahren von ATDD anwenden.

Eine Warnung bei der Lektüre dieses Buchs: Die ersten Kapitel des Buchs, in denen wir den Businessexperten Bernd, den Tester Thorsten und die Programmierer Petra und Alex begleiten, mögen auf den ersten Blick sehr einfach erscheinen, geradezu simpel. Lassen Sie sich von diesem Eindruck nicht täuschen. In diesen Kapiteln geht jede Menge vor sich. Es geht um ein sehr fähiges Team, und einige seiner Fähigkeiten kommen auf leisen Sohlen daher. Achten Sie beispielsweise darauf, wie die Teilnehmer in dem Anforderungsworkshop jede Erwähnung von Technologien vermeiden. Sie konzentrieren sich allein auf die wirtschaftlichen Belange des Systems. Und achten Sie darauf, wie Alex und Thorsten die ersten paar Tests automatisieren und wie Thorsten mit seinen mangelnden Programmiererfahrungen umgeht. Immer wenn er durch ein technisches Detail verwirrt wird, bittet er Alex, es zu erklären, um dann mit Alex den Code so zu ändern, dass dieser selbsterklärend wird. Folgen Sie auch Alex, der immer wieder darauf besteht, die Tests in das Versionskontrollsystem einzuchecken – aber immer erst, wenn der Code funktioniert. Falls Ihnen ATDD noch fremd ist, mögen Ihnen diese Fähigkeiten nicht gleich auffallen, für den Erfolg sind sie aber ganz entscheidend.

Glücklicherweise müssen Sie nicht viel tun, um diese Fähigkeiten selbst zu erlernen, Sie müssen nur weiterlesen. Markus hält immer wieder inne, um zu erklären, was das Team gerade tut und weshalb. Am Ende jeden Kapitels fasst er zusammen, wie das Team zusammengearbeitet hat, was die Denkweise dahinter war und wie die Praktiken angewendet wurden. Im letzten Teil des Buchs bringt Markus alles zusammen, indem er die Prinzipien, auf denen ATDD basiert, in allen Einzelheiten erklärt.

ATDD in der Praxis ist eine wunderbare Einführung in die Akzeptanztestgetriebene Entwicklung. Leuten wie mir, die schon eine Weile ATDD betreiben, gibt das Buch eine neue Sicht der Dinge. Schlussendlich ist es ein Buch, das sich mehrfach zu lesen lohnt. Lesen Sie also, wenden Sie das Gelesene an, lesen Sie wieder. Sie werden jedes Mal etwas Neues und Nützliches lernen.

Dale Emery

Inhaltsverzeichnis

1     Einleitung

Teil I: Flughafenparkplatz

2     Workshop zum Parkgebührenrechner

3     Valet-Parking-Automatisierung

4     Automatisierung der restlichen Parkplätze

5     Wünsche und Zusammenarbeit

Teil II: Ein Softwaresystem für eine Ampelanlage

6     Aller Anfang ist schwer ...

7     Ampelzustände

8     Die erste Kreuzung

9     Entdecken und erforschen Sie

Teil III: Prinzipien Akzeptanztest-getriebener Entwicklung

10    Verwenden Sie Beispiele

11    Spezifizieren Sie gemeinsam

12    Automatisieren Sie wörtlich

13    Bleiben Sie sauber beim Testen

14    Erfolgreiches ATDD

Teil IV: Anhang

A     Cucumber

B     FitNesse

C     Robot Framework

D     Bibliographie

Index

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ß Papier1 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 fünf Stunden und eine Minute muss ich 18,00 € zahlen, genauso wie für 12 oder gar 24 Stunden?

Bernd: Ja, absolut korrekt.

Thorsten: Was wäre aber nun bei 24 Stunden und einer Minute? Wären das 30,00 € oder 36,00 €?

Bernd: Das wären natürlich 36,00 €.

Petra: Wie ist das mit wöchentlichen Limits? Gibt es die beim Valet-Parking?

Bernd: Nein, das wäre im Prinzip schon alles für das Valet-Parking.

Thorsten: Alles klar, dann lassen Sie mich diese Beispiele einfach einmal aufschreiben.

Thorsten schreibt nun die Tabelle 2–1, in der die besprochenen Beispiele vorkommen, und betitelt sie mit »Valet-Parking«.

Petra: Ergeben diese Beispiele für das Valet-Parking einen Sinn?

Bernd: Ja, sie fassen unser Gespräch wunderbar zusammen.

Parkdauer

Parkgebühren

30 min

12,00 €

3 h

12,00 €

5 h

12,00 €

5 h, 1 min

18,00 €

12 h

18,00 €

24 h

18,00 €

1 Tag, 1 min

36,00 €

3 Tage

54,00 €

1 Woche

126,00 €

Tab. 2–1 Vorläufige Beispiele für das Valet-Parking

Kurzzeitparken

Petra: O.K., welche Arten von Parkgebühren gibt es noch? Sie hatten drei verschiedene Typen erwähnt.

Bernd: Wir bieten auch Kurzzeitparkplätze für Besucher an, die Reisende bringen oder abholen.

Petra: Wie viel kostet das?

Bernd: Wir verlangen 2,00 € für die erste Stunde. Für jede weitere halbe Stunde sind weitere 1,00 € fällig.

Thorsten: Gibt es hinsichtlich der Parkdauer Beschränkungen?

Bernd: Nein, die gibt es nicht. Allerdings verlangen wir höchstens 24,00 € an einem Tag.

Petra: Also gibt es eine Obergrenze von 24,00 € pro Tag?

Bernd: Genau.

Thorsten: Und nach Ablauf des ersten Tages wird die erste Stunde mit 2,00 € berechnet oder steigen die Gebühren dann weiter in 30min-Schritten?

Bernd: Oh, das wären dann 25,00 € für einen Tag und eine halbe Stunde.

Thorsten: Wie ist das mit einer wöchentlichen Obergrenze? Gibt es die?

Bernd: Nein. Die Kurzparker bleiben auch nicht für eine ganze Woche, da es ihnen vermutlich zu teuer ist. Die dritte Option ist in solchen Fällen wesentlich attraktiver.

Thorsten: O.K., was halten Sie von dieser Tabelle?

Thorsten hat Tabelle 2–2 erstellt und zeigt sie Bernd und Petra.

Bernd: Genau so verhält sich das.

Parkdauer

Parkgebühren

30 min

2,00 €

1 h

2,00 €

1 h, 30 min

3,00 €

2 h

4,00 €

3 h, 30 min

7,00 €

12 h

24,00 €

12 h, 30 min

24,00 €

1 Tag, 30 min

25,00 €

1 Tag, 1 h

26,00 €

Tab. 2–2 Vorläufige Beispiele für das Kurzzeitparken

Economy- und Langzeitparken

Petra: Was ist nun der dritte Typ von Parkgebühren, den wir berechnen müssen?

Bernd: Da gibt es noch das Economy-Parken. Der Parkplatz liegt weiter draußen vorm Flughafen. Deshalb ist es für die Reisenden preisgünstiger. Um sie zum Terminal zu bringen, haben wir einen Shuttle-Bus.

Petra: Alles klar, und wie günstig ist das?

Bernd: Hier sind die Regeln etwas komplizierter. Zunächst betragen die Gebühren 2,00 € pro Stunde.

Thorsten: An jedem Tag? Oder gibt es für das Wochenende andere Tarife?

Bernd: Nein, der Wochentag spielt keine Rolle.

Thorsten: Also, der Economy-Parkplatz kostet die ersten 30 Minuten wie die ersten 60 Minuten genau 2,00 €, richtig?

Bernd: Genau.

Petra: Na, das klingt ja nicht so kompliziert. Drei Stunden kosten dann vermutlich 6,00 €, während 10 Stunden 20,00 € kosten würden.

Bernd: Ja und nein. Wir haben eine Tagesobergrenze von 9,00 €. Das heißt, dass für die erste bis zur vierten Stunde jeweils 2,00 € erhoben werden. Die fünfte Stunde hebt die Kosten auf die Tagesobergrenze von 9,00 €. Jede weitere Stunde verändert die Gebühr bis zum nächsten Tag nicht mehr.

Thorsten: Also, wir haben eine halbe Stunde, eine Stunde, 2,00 €, drei Stunden 6,00 €, vier Stunden 8,00 €, fünf Stunden 9,00 €, sechs Stunden 9,00 €, 24 Stunden 9,00 €...

Bernd: Ja, so ist es.

Thorsten: O.K., was passiert nun am zweiten Tag? Kommen jetzt 2,00 € dazu oder gleich 9,00 € für den ganzen Tag?

Bernd: Nein, danach kommen weitere 2,00 € zu der Summe pro Stunde und dann geht es wieder bis zur Tagesobergrenze von 9,00 €.

Thorsten: So, ein Tag und eine halbe Stunde kosten 11,00 €, ein Tag und fünf Stunden kosten 18,00 €. Ich nehme an, dass die dritte, vierte, fünfte, ... genauso läuft?

Bernd: Ja, aber da gibt es noch eine weitere Obergrenze. Die wöchentliche Obergrenze liegt bei 54,00 €. Im Prinzip ist der siebte Tag gebührenfrei.

Thorsten: O.K., das habe ich verstanden. Lassen Sie mich zusammenfassen. Hier ist eine Tabelle, die ich während des Gesprächs zusammengetragen habe.

Thorsten zeigt Bernd und Petra die Tabelle 2–3, die mit »Economy-Parken« bezeichnet ist.

Bernd: Das sieht gut aus.

Petra: Warten Sie mal, Bernd. Wie ist das mit sechs Tagen und einer Stunde? Beläuft sich das auf 56,00 € oder eher 54,00 €?

Parkdauer

Parkgebühren

30 min

2,00 €

1 h

2,00 €

3 h

3,00 €

4 h

8,00 €

5 h

9,00 €

6 h

9,00 €

24 h

9,00 €

1 Tag, 1 h

11,00 €

1 Tag, 3 h

15,00 €

1 Tag, 5 h

18,00 €

3 Tage

27,00 €

6 Tage

54,00 €

7 Tage

54,00 €

1 Woche, 2 Tage

72,00 €

3 Wochen

162,00 €

Tab. 2–3 Vorläufige Beispiele für das Economy-Parken

Bernd: Nein, das sind immer noch 54,00 €, da der siebte Tag gebührenfrei ist. Aber vielleicht sollten wir das Beispiel mit aufnehmen.

Thorsten: Das habe ich bereits getan.

Petra: Alles klar, das war alles zum Thema Parkgebühren?

Bernd: Nein, da gibt es noch zwei Varianten beim Economy-Parken. Beim Langzeitparken in der Garage betragen die Gebühren 2,00 € pro Stunde bis zu 12,00 € am Tag und den siebten Tag ebenfalls umsonst. Ohne Garage kostet das Langzeitparken 2,00 € pro Stunde und maximal 10,00 € am Tag und der siebte Tag ist auch hier gebührenfrei.

Thorsten: Also, wie geben das diese zwei Tabellen wieder?

Thorsten hat die Tabellen 2–4 und 2–5 erzeugt und zeigt sie Bernd und Petra.

Bernd: Jawoll, das sieht gut aus.

Petra: Eine Sache bereitet mir noch Kopfzerbrechen. Was das 24-Stunden-Beispiel angeht: Was passiert, wenn man um 23:00 Uhr ankommt und bis zum nächsten Tag um 23:00 Uhr parkt? Ergibt das zusammen einen Tag plus den Folgetag, also 20,00 € insgesamt?

Bernd: Nein, dafür nehmen wir 10,00 €, da die Gesamtparkdauer 24 Stunden beträgt.

Thorsten: Wird das bei mehreren Tagen Parkdauer auf dem Parkplatz genauso gehandhabt?

Bernd: Auf jeden Fall. Die Tagesbeschränkung bezieht sich auf die Gesamtparkdauer, nicht auf die Tagesgrenzen im Kalender oder auf der Armbanduhr.

Parkdauer

Parkgebühren

30 min

2,00 €

1 h

2,00 €

3 h

6,00 €

6 h

12,00 €

7 h

12,00 €

24 h

12,00 €

1 Tag, 1 h

14,00 €

1 Tag, 3 h

18,00 €

1 Tag, 7 h

24,00 €

3 Tage

36,00 €

6 Tage

72,00 €

6 Tage, 1 h

72,00 €

7 Tage

72,00 €

1 Woche, 2 Tage

96,00 €

3 Wochen

216,00 €

Tab. 2–4 Vorläufige Beispiele für das Langzeitparken in der Garage

Parkdauer

Parkgebühren

30 min

2,00 €

1 h

2,00 €

3 h

6,00 €

4 h

8,00 €

5 h

10,00 €

6 h

10,00 €

24 h

10,00 €

1 Tag, 1 h

12,00 €

1 Tag, 3 h

16,00 €

1 Tag, 6 h

20,00 €

3 Tage

30,00 €

6 Tage

60,00 €

6 Tage, 1 h

60,00 €

7 Tage

60,00 €

1 Woche, 2 Tage

80,00 €

3 Wochen

180,00 €

Tab. 2–5 Vorläufige Beispiele für das Langzeitparken auf dem Parkplatz

Wesentliche Beispiele

Thorsten: Jetzt sind wir fast fertig. Wir haben noch einen letzten Schritt vor uns, den wir bei all diesen Beispielen durchführen müssen. Ich denke, wir haben jetzt alle die Gebührenordnungen verstanden. Ich würde jetzt aber gern die Anzahl der Beispiele reduzieren, um nur das Wesentliche der Gebührenordnung mit ihnen wiederzugeben. Lassen Sie uns daher noch ein letztes Mal die Tabellen durchsehen und schauen, was wir weglassen können und sollten.

Bernd: Lassen Sie uns hinten anfangen. Ich würde gerne einige Langzeit-Parkplatz-Beispiele herausnehmen.

Bernd streicht einige der Beispiele beim Langzeitparken auf dem Parkplatz in der Tabelle durch. Das Ergebnis sehen Sie in Tabelle 2–6.

Petra: