Übrigens ist BDD aus der testgetriebenen Entwicklung hervorgegangen. Über BDD bzw. Behavior Driven Development habe ich bereits gestern geschrieben.

Klassisch und fast schon nostalgisch hat man und praktiziert man die Entwicklung heute noch nach dem Wasserfall- oder dem V-Modell-Prinzip. Man entwickelt die Tests parallel zum und unabhängig vom zu testenden System oder sogar erst nachdem die Anwendung „fertiggestellt“ wurde. Aufgrund dieser Tatsache resultiert meist daraus, dass der Code schwer testbar ist und somit der Aufwand für die Tests verhältnismäßig hoch ausfällt. Darüber hinaus kommt es auch vor, dass die Tests nicht die gewünschten oder erforderlichen Testabdeckungen und Ergebnisse liefern, die man sich erhofft.

Dies kann unter anderem daran liegen, dass die fehlende oder mangelnde Testbarkeit des Systems auf die Nutzung von Fremdkomponenten zurückzuführen ist. Auch die Verweigerung einer Investition in nicht-funktionale Programmteile seitens der Entscheider bzw. Unternehmensführung kann ein Grund dafür sein. So im Sinne von, „Arbeit, von der man später im Programm nichts sieht, seien vergeudete Ressourcen.“ Die Erstellung von Tests unter Zeitdruck, rein um die gewünschte Testabdeckung zu erzielen ist ebenfalls ein Grund dafür. Nicht selten, ist es aber auch die Nachlässigkeit und mangelnde Disziplin der Entwickler bei der Testerstellung. An dieser Stelle sein auch das White-Box-Testing zu erwähnen, den ich aber in einem zukünftigen Beitrag thematisieren werde.

Die Methode der testgetriebenen Entwicklung versucht den Nachteilen entgegenzuwirken und dabei auch ein auf die Aufgabenstellung der Software besser angepasstes und wartbareres Softwaredesign zu liefern.

Alles in allem ist es eine Tatsache, dass man bei der Anwenung von testgetriebener Entwicklung im Schnitt bis zu 45 Prozent aller Fehler erkennen bzw. vermeiden kann. Im Vergleich dazu, werden beim reinen Einsatz von Unittests im Schnitt nur bis zu 30 Prozent der Fehler erkannt.

Wie funktioniert TDD?

Bei der testgetriebenen Entwicklung ist zwischen dem Testen im Großen (Integrationstests, Systemtests, Akzeptanztests) und dem Kleinen Modultests (Unit Tests) zu unterscheiden.

Testgetriebene Entwicklung mit Unit-Tests (Stichwort Tests First bzw. Middle-Out-TDD)

Man schreibt Unit-Tests in der Regel vor der eigentlichen Entwicklung der Anwendung. Es ist nicht festgelegt, ob der Entwickler, der die Implementierung vornimmt, auch die Unit-Tests erstellt. Es ist erlaubt, dass mehrere fehlschlagende Unit-Tests gleichzeitig existieren. Die Umsetzung des von einem Unit-Test geforderten Verhaltens in der Anwendung kann zeitlich verschoben werden.

Die Methode Tests First kann als Vorstufe der testgetriebenen Entwicklung betrachtet werden.

TDD nach Kent Beck

Man entwickelt Unit-Tests und die mit ihnen getesteten Units stets parallel. Die eigentliche Entwicklung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile, die man im englischen schlicht als Red, Green und Refactor bezeichnet.

1. Red: Schreibe einen Test, der ein neues zu programmierendes Verhalten (die Funktionalität) prüfen soll. Dabei fängt man mit dem einfachsten Beispiel an. Ist die Funktion schon älter, kann dies auch ein bekannter Fehler oder eine neu zu implementierende Funktionalität sein. Dieser Test wird vom vorhandenen Programmcode erst einmal nicht erfüllt und muss folglich fehlschlagen.
   
2. Green: Ändere den Programmcode mit möglichst wenig Aufwand ab und ergänze ihn, bis er nach dem anschließend angestoßenen Testdurchlauf alle Tests besteht.
   
3. Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Duplizierten Code), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus. In dieser Phase darf kein neues Verhalten eingeführt werden. Nach jeder Änderung werden die Tests ausgeführt. Der Fehlschlag der Tests verbietet es, die offenbar fehlerhafte Änderung in den bereits genutzten Code zu übernehmen. Ziel des Aufräumens ist es, den Code schlicht, elegant und verständlich zu machen.

Diese drei Schritte wiederholt man so lange und so oft, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler keine sinnvollen weiteren Tests mehr einfallen, die vielleicht noch scheitern könnten. Die so behandelte programmtechnische Einheit (Unit) wird dann als einstweilen fertig angesehen. Die gemeinsam mit ihr geschaffenen Tests werden beibehalten, damit auch nach künftigen Iterationen und Änderungen getestet werden kann, ob die schon erreichten Aspekte des Verhaltens weiterhin erfüllt werden.

Damit die – auch Transformationen genannten – Änderungen in Schritt 2 zum Ziel führen, muss jede Änderung zu einer allgemeineren Lösung führen. Sie darf also nicht etwa nur den aktuellen Testfall auf Kosten anderer behandeln. Tests, die immer mehr ins Detail gehen, treiben den Code so zu einer immer allgemeineren Lösung. Die Beachtung der Transformationsprioritäten führt dabei regelmäßig zu effizienteren Algorithmen und damit Anwendungen. Die konsequente Befolgung dieser Vorgehensweise ist eine evolutionäre Entwurfsmethode, indem jede der einzelnen Änderungen bzw. Iterationen das System von Natur aus weiterentwickelt.

Testgetriebene Entwicklung mit System- oder Akzeptanztests (Stichwort Outside-In-TDD)

Wie bereits erwähnt, entwickelt man Systemtests bei der testgetriebenen Entwicklung immer vor dem System selbst oder aber man erstellt zumindest das Konzept dafür. Aufgabe der Systementwicklung ist bei testgetriebener Entwicklung nicht mehr, wie klassisch, schriftlich formulierte Anforderungen zu erfüllen, sondern spezifizierte Systemtests zu bestehen.

Akzeptanztestgetriebene Entwicklung (ATDD)

ATDD ist zwar mit testgetriebener Entwicklung verwandt, unterscheidet sich jedoch in der Vorgehensweise von testgetriebener Entwicklung. Akzeptanztestgetriebene Entwicklung ist ein Kommunikationswerkzeug zwischen dem Kunden bzw. den Anwendern, den Entwicklern und den Testern. Es soll sicherstellen, dass die Anforderungen gut beschrieben sind. Akzeptanztestgetriebene Entwicklung verlangt keine Automatisierung der Testfälle, wenngleich diese für das Regressionstesten hilfreich sind. Die Tests bei akzeptanztestgetriebener Entwicklung müssen dafür auch für Nicht-Entwickler lesbar sein. Die Tests der testgetriebenen Entwicklung können in vielen Fällen aus den Tests der akzeptanztestgetriebenen Entwicklung abgeleitet werden.

Der Beitrag TDD – Test Driven Development – Qualitativ hochwertige Software von Anfang an erschien zuerst auf CEOsBay.

Die verhaltensgetriebene Entwicklung kombiniert die allgemeinen Techniken und Prinzipien von TDD. Unter Anderem auch mit Ideen aus dem bereichsgetriebenen Design, der objektorientierten Analyse und dem objektorientierten Design, um Softwareentwicklungs- und Managementteams gemeinsame Tools und einen gemeinsamen Prozess für die Zusammenarbeit bei der Softwareentwicklung zur Verfügung zu stellen.

So wie man die Softwareentwicklung sowohl von geschäftlichen Interessen als auch von technischem Verständnis voranbringt, setzt die BDD-Praxis den Einsatz spezieller Softwaretools zur Unterstützung des Entwicklungsprozesses voraus. Obwohl man diese Tools oft speziell für den Einsatz in BDD-Projekten entwickelt, kann man sie als spezialisierte Formen der Tools zur Unterstützung der testgetriebenen Entwicklung betrachten. Diese Tools dienen dazu, die allgegenwärtige Sprache, die ein zentrales Thema von BDD ist, zu automatisieren.

BDD wird weitestgehend durch die Verwendung einer einfachen domänenspezifischen Sprache (DSL = Domain-Specific-Language) mit natürlichen sprachlichen Konstrukten (z.B. deutsch- oder englischsprachige Sätze) erleichtert, mit denen man das Verhalten und die erwarteten Ergebnisse ausdrückt. Testskripte sind seit langem eine beliebte DSLs mit unterschiedlichem Grad an Raffinessen. BDD gilt als effektive technische Praxis, insbesondere wenn der „Problemraum“ des zu lösenden Geschäftsproblems komplex ist.

Wie funktioniert BDD?

Im Grunde genommen besteht Behavior Driven Development aus den folgenden Elementen:

• Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, der Enduser, des Betriebs und von Insidern.
• Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, des externen Verhaltens und des gewünschten Verhaltens der Software.
• Automatisierung der Fallbeispiele unter Verwendung von Mock-Objekten zur Simulation von noch nicht implementierten Softwareteilen.
• Sukzessive Implementierung der Softwareteile und dem Ersetzen der Mock-Objekte.

Dadurch entsteht eine automatisiert prüfbare Beschreibung der zu entwickelnden Software, die jederzeit die Richtigkeit der bereits umgesetzten Teile der Software überprüfen lässt.

Wichtig ist hierbei, dass die Beschreibung nicht die Implementierung der Anwendung vorgibt, sondern den Zweck der Anwendung in Form von Anwendungsbeispielen.

Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispiele, sogenannten Szenarien beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarien ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache „Gherkin“. Man kann es auch in verschiedenen Behavior-Driven-Development-Implementierungen verwenden. Diese Sprache gibt es sowohl mit englischen Schlüsselwörtern (Given, When, Then, And, …), deutschen (Gegeben, Wenn, Dann, Und, …) und in weiteren Sprachen. Mehr dazu in meinem Beitrag über Cucumber bzw. Gherkin.

Fazit

Behavior Driven Development (BDD) ist eine agile Softwareentwicklungs-Methode, die sich auf die Zusammenarbeit zwischen Entwicklern, Business Analysten und Kunden konzentriert, um sicherzustellen, dass die erstellte Software den Bedürfnissen der Anwender entspricht. BDD ist eine Erweiterung des Test Driven Developments (TDD) und legt den Schwerpunkt auf die Definition von klaren, verständlichen Anforderungen und Tests, die das Verhalten der Anwendung aus der Perspektive des Nutzers beschreiben. Durch die Verwendung von gemeinsamer Sprache und konkreten Beispielen kann man die Kommunikation zwischen den Stakeholdern verbessern und Missverständnisse vermeiden. Das Ergebnis ist eine höhere Qualität der Software, eine schnellere Markteinführung und eine höhere Kundenzufriedenheit.

Der Beitrag BDD – Behavior Driven Development – Software, die den Anforderungen der Kunden entspricht erschien zuerst auf CEOsBay.

Cucumber wurde ursprünglich in der Programmiersprache Ruby für Ruby-Anwendungen geschrieben. In der Zwischenzeit unterstützt es aber auch andere Programmiersprachen wie Java und alle anderen auf der Java Virtual Machine gängigen Programmiersprachen sowie C++ und JavaScript. Darüber hinaus gibt es Projekte, die Cucumber noch für weitere Programmiersprachen zur Verfügung stellen und sich als Teil der Cucumber-Familie sehen. Darunter beispielsweise SpecFlow, eine Implementierung für C#.

Wie funktioniert Cucumber?

Wie auch bei den meisten anderen BDD-Frameworks werden in Cucumber Funktionalitäten mittels der Beschreibungssprache „Gherkin“ beschrieben. Gherkin verwendet natürliche Schriftsprache als Grundlage. Lediglich bestimmte Schlüsselwörter werden besonders behandelt.

Gherkin

Gherkin ist die Sprache, die Cucumber verwendet, um Testfälle zu definieren. Sie ist so konzipiert, dass sie sich nicht-technisch und für den Menschen lesbar gestaltet. Es beschreibt Anwendungsfälle in Bezug auf ein Softwaresystem. Der Zweck hinter der Gherkin-Syntax ist die Förderung verhaltensorientierter Entwicklungspraktiken in einem Entwicklungsteam, einschließlich Geschäftsanalysten und Managern. Sie zielt darauf ab, bereits in den ersten Phasen der Anforderungsdefinition durch die Geschäftsleitung und in anderen Phasen des Entwicklungslebenszyklus einer Anwendung feste, eindeutige Anforderungen durchzusetzen.

Syntax

Die Syntax ist ähnlich wie bei Python zeilenorientiert aufgebaut. Die Struktur einer Datei wird durch Leerzeichen und andere Steuerzeichen definiert. # wird als Zeilen bzw. Kommentarzeichen verwendet und kann an jeder beliebigen Stelle in einer Datei stehen. Anweisungen sind jede nicht leere und nicht kommentierte Zeile. Sie bestehen aus einem konkreten Gherkin-Schlüsselwort, gefolgt von einer Zeichenkette.

Alle Gherkin-Dateien haben die Dateierweiterung .feature. Sie enthalten eine einzelne Feature-Definition für das zu testende System und sind ein ausführbares Testskript.

Neben der Bereitstellung eines Skripts für automatisierte Tests ist die Syntax von Gherkin so konzipiert, dass sie eine einfache Dokumentation des zu testenden Codes ermöglicht. Gherkin unterstützt derzeit Schlüsselwörter in Dutzenden von Sprachen.

Schlüsselwörter der Gherkin Sprache

• Feature: Name bzw. die Bezeichnung des Features
• Rule: Regeln des Features
• Example oder Scenario: Die Bezeichnung des Szenarios (Beispielsweise „Die erfolgreiche Anmeldung mit gültigen Anmeldeinformationen.“)
• Given, When, Then, And, But für die steps (oder *)- Vorbedingungen (Gegeben sei), die Aktion, die ausgeführt wird bzw. die Erweiterung durch andere Schlüsselwörter um die Aktion die ausgeführt wird zu ergänzen bzw. zu erweitern. (Der User gibt beispielsweise seine Zugangsdaten, Username and Password ein), gefolgt von der erwarteten Reaktion des Systems (Beispielsweise die Nachricht, bei einem erfolgreichen Login.)
• Background – Ein Background ermöglicht es einem, den nachfolgenden Scenarios einen gewissen Kontext hinzuzufügen. Es kann einen oder mehrere Vorgegebene Schritte enthalten, die vor jedem Scenario aber nach jedem Before hook ausgeführt werden.
• Scenario Outline oder Scenario Template – Damit lässt sich dasselbe Szenario mehrmals mit unterschiedlichen Wertekombinationen ausführen.
• Examples oder Scenarios – Eine Scenario Outline muss einen oder mehrere Abschnitte mit Examples bzw. Scenarios enthalten. Sie dienen als Steps bzw. Interpretationsvorlage, die nie direkt ausgeführt werden. Stattdessen wird die Szenariogliederung einmal für jede Zeile mit den darunter liegenden Abschnitten von Examples ausgeführt.

Gherkin in deutscher Sprache

Um eine Funktionalität auf Deutsch zu schreiben, muss am Beginn des Features # language: de angegeben werden. Damit sind u.A. folgende deutsche Schlüsselwörter verfügbar:

• Funktionalität
• Grundlage
• Szenario
• Szenariogrundriss
• Beispiele
• Angenommen
• Gegeben sei
• Wenn
• Dann
• Und und Aber, sowie *

Die Command line (CL)

Cucumber verfügt über eine integrierte Kommandozeilenschnittstelle, die eine umfassende Liste von Anweisungen enthält. Wie die meisten Kommandozeilen-Tools bietet Cucumber die Option –help an, die eine Zusammenfassung der Befehle liefert, die diese Command Line akzeptiert.

$ cucumber --help
        -r, --require LIBRARY|DIR        Require files before executing the features.
        --i18n LANG                      List keywords for in a particular language.
                                         Run with "--i18n help" to see all languages.
        -f, --format FORMAT              How to format features (Default: pretty).
        -o, --out [FILE|DIR]             Write output to a file/directory instead of
        ...

Fazit

Gherkin ist nicht nur zum Schreiben von automatisierten Tests geeignet. Man kann Gherkin grundsätzlich auch dazu verwenden, um strukturierte Tests zu erstellen, die man später als Projektdokumentation verwendet kann. Erst die Eigenschaft, strukturiert zu sein, gibt uns die Möglichkeit zu automatisieren.

Sowohl die Sprache Gherkin wie auch das Tool Cucumber, bieten weitaus mehr Funktionalitäten, die ich hier nicht thematisiert habe. Zumal ich auch recht frisch in dieses Thema eingestiegen bin. So ist beispielsweise ein Datengetriebenes Szenario mithilfe von Tabellen möglich. Fernab können verschiedene Schritte, die im Prinzip das Gleiche tun, über Platzhalter definiert werden.

Um solche und weitere Vorteile zu nutzen, ist neben Cucumber oder anderen Testtools vor allem Disziplin beim Verfassen der Dokumentation bzw. der Gherkin Dokumente gefragt. Gleichzeitig müssen die formulierten Schritte präzise genug sein, um die gewünschten Verhaltensweisen ausreichend genau zu beschreiben. Ansonsten zerfällt die Abstraktion und Gherkin Dokumente werden lediglich zu etwas besser lesbaren Testskripten statt dem Ansatz des BDD zu folgen.

Cucumber lässt sich auch mit IntelliJ nutzen. Aber darüber gibt es dann in naher Zukunft einen weiteren Beitrag.

Der Beitrag Cucumber – Das kollaborative Tool für Behavior Driven Development erschien zuerst auf CEOsBay.