# Testautomatisierung mit Behavior-Driven Development (BDD) > Behavior-Driven Development erstellt ausführbare Spezifikationen mit der Given-When-Then-Syntax. BDD vereinfacht die Testautomatisierung und stellt sicher, dass Dokumentation und Implementierung übereinstimmen. - Date: 2021-02-20 - Source: https://romanoroth.com/de/blogs/testautomatisierung-mit-behavior-driven-development-bdd/ - Tags: BDD, Testautomatisierung, Qualitätssicherung, Gherkin, SpecFlow, Cucumber, Software Testing, Agilität, SDLC Die Automatisierung von Tests ist eine komplexe und anspruchsvolle Aufgabe. Der iterative Ansatz im Entwicklungsprozess bedeutet auch, dass die automatisierten Tests kontinuierlich angepasst werden müssen. Behaviour-Driven Development (BDD) kann eingesetzt werden, um die Testautomatisierung zu vereinfachen und zu beschleunigen. Von [Romano Roth](https://www.linkedin.com/in/romanoroth/) und [Marcel Stalder](https://www.linkedin.com/in/mstd/) ![Weisses DevOps-Zahnrad-Symbol als Unendlichkeitsschleife über einem Hintergrund aus Papierpfeilen](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-1.jpg) Agile und iterative Softwareentwicklung mit [DevOps](https://www.zuehlke.com/blog/en/satisfied-end-users-thanks-to-devops/), einschliesslich einer automatisierten Build- und Deployment-Pipeline, erfordert eine gute und automatisierte Testabdeckung. Die Definition von Anforderungen für Geschäftssoftware ist keine triviale Aufgabe. Während die Grundidee einer neuen Funktionalität in der Regel schnell kommuniziert wird, liegen die Herausforderungen im Detail. Product Owner (PO), Business-Analysten (BA) und Requirements Engineers (RE) verwenden beispielsweise verschiedene Formen zur Definition von Anforderungen wie Prosatext, Entscheidungstabellen oder Sequenzdiagramme. Anforderungen werden auch mündlich an die Entwickler (DEV) kommuniziert, wenn etwas fragwürdig oder mehrdeutig ist oder wenn Anforderungen nicht anderweitig dokumentiert wurden. Dies führt zu mehreren Transformationsschritten: 1. Die Anforderungen aus verschiedenen Quellen und in verschiedenen Formaten müssen an die Entwickler kommuniziert werden. 1. Die Entwickler setzen die Anforderungen in Quellcode um, erstens für die eigentliche Implementierung und zweitens für die automatisierten Tests. 1. Die Verantwortlichen für Qualitätssicherung (QA) müssen wiederum nicht nur die Anforderungen kennen, sondern auch wissen, wie diese in der Praxis umgesetzt wurden. Anforderungen bleiben jedoch in der Regel nicht fix. Sie ändern sich. Also beginnt der Transformationsprozess von neuem und das Delta zur bestehenden Implementierung muss identifiziert werden. Dieser Schritt ist zeitaufwändig und erschwert das Testen und die Qualitätssicherung bei Änderungen. Das ist nicht ideal, wenn man mit einer automatisierten [CI/CD-Pipeline](https://www.zuehlke.com/blog/en/what-is-ci-cd/) arbeitet, die kurze Entwicklungs- und Testzyklen hat. ![Diagramm, wie Anforderungen vom PO über Prosa, Matrix oder Flow zu Devs gelangen und dann in Implementierung und Test übersetzt werden](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-2.jpg) ## Die ausführbare Spezifikation Was wäre, wenn die Spezifikation ausführbar wäre? Das würde die Transformationsschritte vereinfachen, es gäbe weniger Missverständnisse und der Entwicklungsprozess würde beschleunigt. Ein zusätzlicher Vorteil ist die Dokumentation der Systemfunktionalität, die auch wirklich der aktuellen Implementierung entspricht. Das sollte zu besserer Qualität und damit zu weniger Fehlern führen. Eine Möglichkeit für eine ausführbare Spezifikation ist [Behaviour-Driven Development (BDD)](https://de.wikipedia.org/wiki/Behavior_Driven_Development), ein agiler Softwareentwicklungsprozess, der seine Wurzeln im [Test-Driven Development (TDD)](https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung) hat und Ideen aus dem [Domain-Driven Design (DDD)](https://de.wikipedia.org/wiki/Domain-driven_Design) übernimmt. In BDD kann das gewünschte Verhalten einer Software direkt in einer User Story definiert werden, zum Beispiel: ![Gherkin-Vorlage mit Feature, rollenbasierter User Story und zwei Given-When-Then-Szenarien](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-3.png) Die Syntax [Gherkin](https://cucumber.io/docs/gherkin/reference/), die Given-When-Then als Grundstruktur zur Beschreibung der Vorbedingung, der Aktion und des erwarteten Ergebnisses verwendet, wird für die Definition eingesetzt. Da es sich um reinen Text handelt, kann die Verhaltensbeschreibung mit verschiedenen Technologien verwendet werden, darunter: - SpecFlow für .NET - Cucumber.js für JavaScript - Cucumber-JVM für Java - Behave für Python ## Ein praktisches Beispiel Beginne mit der Spezifikation des gewünschten Verhaltens. Ein Beispiel ist eine (vereinfachte) Berechnung des Marktwerts einer Position in einem Wertpapierportfolio: ![Gherkin-Beispiel: Marktwertberechnung, Instrument mit Rate 100 und Menge 10 ergeben einen Positionswert von 1000](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-4.png) Das BDD-Tool liest diese Spezifikation und generiert für jede Given/When/Then-Zeile eine Step Definition. Step Definitions sind Methoden im Testcode und dienen als Verbindung zu den Domänenklassen. Die Aufgabe der Entwickler ist es nun, die generierten Step Definitions basierend auf der Spezifikation zu implementieren. Die Spezifikation wird dann über den Runner des verwendeten Testframeworks ausgeführt. ![BDD-Ablauf: Spezifikation erzeugt Tests und Step Definitions, die der Dev implementiert und ein Runner gegen die Domäne ausführt](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-5.jpg) Wie die Domänenklassen nahelegen, wird BDD hier für Unit Tests eingesetzt, um die Geschäftslogik zu testen. Die automatisierte Ausführung der Spezifikation ist jedoch nicht auf Unit Tests beschränkt, sondern kann auf allen Ebenen der Testpyramide eingesetzt werden. Viele BDD-Beispiele arbeiten auf Systemebene und automatisieren UI-Tests mit Selenium. Es können jedoch auch Integrationstests durchgeführt werden, um beispielsweise Daten in einer Datenbank zu erstellen oder zu verifizieren. ![Testpyramide mit Unit-, Integrations- und System-Ebene, jede gespeist aus derselben ausführbaren Spezifikation](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-6.jpg) ## Der Entwicklungsprozess Die Spezifikationen sind in der Regel wesentlich komplexer als das vereinfachte praktische Beispiel. Deshalb wird vor dem eigentlichen Implementierungsprozess ein Solution Design (SD) erstellt. Dieses SD beschreibt unter anderem die Ist-Situation, die Soll-Situation und die Implementierungsschritte (Stories). Das Schlüsselelement ist die Spezifikation in Gherkin. Ausgehend von der User Story für das Solution Design wird diese Spezifikation ständig erweitert und verfeinert. Die Spezifikation ist auch ein Schlüsselelement in den Reviews, um die Anforderungen und die aktuelle Implementierung zu überprüfen. ![Spezifikationszentrierter BDD-Zyklus mit Solution Design, Story Review, Code Review und Code Test sowie den jeweils beteiligten Rollen](/images/blog/test-automation-with-behavior-driven-development-bdd-inline-7.jpg) Behaviour-Driven Development (BDD) mit der Spezifikation des Anwendungsverhaltens in Gherkin ist ein empfehlenswerter Schritt für die automatisierte Prüfung komplexer fachlicher Anforderungen. Da die ausführbare Spezifikation bereits zu Beginn der Entwicklungsarbeit vorliegt, lässt sich Test-Driven Development (TDD) einfach umsetzen. Wenn eine Spezifikation konsistent sein soll, müssen alle am Entwicklungsprozess Beteiligten eine gemeinsame Sprache verwenden. Deshalb ist Domain-Driven Design (DDD) mit einem zentralen und dokumentierten Domänenmodell eine gute Grundlage. Dank Behaviour-Driven Development (BDD) und einer automatisierten Build- und Deployment-Pipeline können Organisationen sowohl die Feedback-Zyklen als auch die Durchsatzgeschwindigkeit erhöhen. So können sie schneller reagieren und ihre Kunden mit ständigen Innovationen beeindrucken. Dank DevOps werden Prozesse von der Entwicklung über das Release bis zum Betrieb automatisiert und optimiert. Das steigert die Effizienz, was wiederum die mit Änderungen verbundenen Kosten senkt.
Originalbeitrag: [Medium](https://romano-roth.medium.com/test-automation-with-behavior-driven-development-bdd-333a490b0a65)