Cucumber-JVM: Wie BDD Ihren Softwareentwicklungsprozess revolutionieren kann

Cool as a Cucumber

Klaus Bayrhammer


Ein angenehmer Nebeneffekt des BDD ist, dass bei jedem neuen Feature eine Reihe neuer automatisierter Akzeptanztests erstellt wird. Doch deswegen wurde diese Technik eigentlich nicht entwickelt. Hauptsächlich versucht BDD, die Zusammenarbeit zwischen Kunden, Entwicklern und Testern zu stärken, indem Anforderungen im Team diskutiert und in einer gemeinsamen Domänensprache beschrieben werden. Diese Anforderungen werden so festgehalten, dass sie in weiterer Folge als automatisierte Akzeptanztests umgesetzt werden können.

Was ist BDD?

Im Grunde ist das BDD eine Kombination aus Domain-driven Design und Test-driven Development. Doch wie schafft es BDD, diese bewährten Methoden zu vereinen, haben beide doch einen sehr unterschiedlichen Fokus?

Domain-driven Design propagiert ein Softwaredesign, das auf Basis der Fachlogik entsteht. Fachliche Zusammenhänge werden in eigenen Modellen abgebildet. Der Fokus liegt auf der Fachlichkeit statt auf der technischen Umsetzung. Eine Grundlage des BDD ist eine gemeinsame Domänensprache, die Kunden, Testern und Entwicklern ein gemeinsames Verständnis von Problemstellungen ermöglicht. In dieser Sprache können Akzeptanztests in einer für alle Beteiligten verständlichen Sprache spezifiziert werden. Beim gemeinsamen Erarbeiten dieser Akzeptanztests werden die Kundenanforderungen von Entwicklern und Testern kritisch hinterfragt. Logische Probleme im Prozess können so frühzeitig erkannt und gelöst werden. Zusätzlich ermöglicht diese „Ubiquitous Language“, die gemeinsame Domänensprache, eine effiziente Kommunikation zwischen Kunden und dem Entwicklungsteam, da sie sowohl fachlich als auch technisch unmissverständlich ist [1].

Test-driven Development fordert das Entwickeln von Tests vor dem Umsetzen der fachlichen Anforderungen. Damit sollten sich Entwickler auf das eigentliche Problem konzentrieren, das zuerst in einem Test abgebildet werden muss. Erst danach darf die konkrete technische Lösung des Problems ausgearbeitet werden. BDD basiert auf dem Grundsatz, dass fachliche Abläufe, die in der gemeinsamen Domänensprache formuliert wurden, die Grundlage für Akzeptanztests sind. Diese Akzeptanztests sind vollkommen unabhängig von der technischen Umsetzung und konzentrieren sich lediglich auf fachliche Abläufe.

BDD in der Praxis

Wie bei jedem Entwicklungsprozess müssen zuerst die funktionalen Anforderungen gesammelt werden. In agilen Vorgehensmodellen werden diese oft als User Stories definiert. Im Normalfall werden diese Anforderungen von ...

Cucumber-JVM: Wie BDD Ihren Softwareentwicklungsprozess revolutionieren kann

Cool as a Cucumber

Klaus Bayrhammer


Ein angenehmer Nebeneffekt des BDD ist, dass bei jedem neuen Feature eine Reihe neuer automatisierter Akzeptanztests erstellt wird. Doch deswegen wurde diese Technik eigentlich nicht entwickelt. Hauptsächlich versucht BDD, die Zusammenarbeit zwischen Kunden, Entwicklern und Testern zu stärken, indem Anforderungen im Team diskutiert und in einer gemeinsamen Domänensprache beschrieben werden. Diese Anforderungen werden so festgehalten, dass sie in weiterer Folge als automatisierte Akzeptanztests umgesetzt werden können.

Was ist BDD?

Im Grunde ist das BDD eine Kombination aus Domain-driven Design und Test-driven Development. Doch wie schafft es BDD, diese bewährten Methoden zu vereinen, haben beide doch einen sehr unterschiedlichen Fokus?

Domain-driven Design propagiert ein Softwaredesign, das auf Basis der Fachlogik entsteht. Fachliche Zusammenhänge werden in eigenen Modellen abgebildet. Der Fokus liegt auf der Fachlichkeit statt auf der technischen Umsetzung. Eine Grundlage des BDD ist eine gemeinsame Domänensprache, die Kunden, Testern und Entwicklern ein gemeinsames Verständnis von Problemstellungen ermöglicht. In dieser Sprache können Akzeptanztests in einer für alle Beteiligten verständlichen Sprache spezifiziert werden. Beim gemeinsamen Erarbeiten dieser Akzeptanztests werden die Kundenanforderungen von Entwicklern und Testern kritisch hinterfragt. Logische Probleme im Prozess können so frühzeitig erkannt und gelöst werden. Zusätzlich ermöglicht diese „Ubiquitous Language“, die gemeinsame Domänensprache, eine effiziente Kommunikation zwischen Kunden und dem Entwicklungsteam, da sie sowohl fachlich als auch technisch unmissverständlich ist [1].

Test-driven Development fordert das Entwickeln von Tests vor dem Umsetzen der fachlichen Anforderungen. Damit sollten sich Entwickler auf das eigentliche Problem konzentrieren, das zuerst in einem Test abgebildet werden muss. Erst danach darf die konkrete technische Lösung des Problems ausgearbeitet werden. BDD basiert auf dem Grundsatz, dass fachliche Abläufe, die in der gemeinsamen Domänensprache formuliert wurden, die Grundlage für Akzeptanztests sind. Diese Akzeptanztests sind vollkommen unabhängig von der technischen Umsetzung und konzentrieren sich lediglich auf fachliche Abläufe.

BDD in der Praxis

Wie bei jedem Entwicklungsprozess müssen zuerst die funktionalen Anforderungen gesammelt werden. In agilen Vorgehensmodellen werden diese oft als User Stories definiert. Im Normalfall werden diese Anforderungen von ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang