Schon gehört von BDD-Tests? Nein, dann schlage ich dir unbedinget das Buch "BDD in Action" vor, das dir das Behavior-Driven Development (BDD) Entwicklungsmodell vermittelt und dir zeigt, wie du es in deinem vorhandenen Entwicklungsprozess integrieren kannst. Zunächst lernst du, wie du BDD bei der Anforderungsanalyse anwendest, um Features samt den dazugehörigen Szenarien zu definieren. Anschließend erfährst du, wie du Acceptance Kriterien automatisierst und mithilfe von Tests den Entwicklungsprozess steuerst. Auf dem Weg dorthin wirst du die BDD-Grundlagen auf Codeebene anwenden, um wartungsfähigeren und besser dokumentierten Code zu schreiben.
Hier ein einfaches Test scenario:
// Feature written in Cucumber style
Given I have 5 EUR on my account
When I deposit 7 EUR into my account
Then my account balance is 12 EUR
Das BDD Modell ist an das Konzept des TDD (Test-Driven Development) Ansatzes angelehnt, geht jedoch einen Schritt oder sagen wir mehrere Schritte weiter.
Sowohl bei BDD als auch bei TDD besteht der große Vorteil darin, dass man nicht mit dem eigenen Applikations Code beginnt, sondern die einzelnen requirements runterbricht in ausführbare Tests (TDD) oder Szenarien (BDD).
Sowohl bei TDD als auch BDD hat man gleich die notwendigen Tests, die nur mehr automatisiert gehören. Bei TDD sind es einfache Test Methoden. Beim BDD Ansatz hat man aber nicht nur Test Methoden (diese werden übrigens Steps genannt) sondern man hat zusätzlich on top aussagekräftige Feature Files, die die einzelnen Szenarien beschreiben. Feature Files samt den darin enthaltenen Szenarien stellen also gleich eine Doku dar, oder auch Living Documentation genannt.
Es ist nachgewiesen, dass Software Projekte die den BDD Ansatz erfolgreich umsetzen in der Regel erfolgreicher abschneiden, als Software Projekte, die unstruktiert testen. Wenn auch in den gescheiterten Projekten zwar Unit Tests und Integration Tests verfasst werden, fehlt diesem Ansatz verglichen mit dem BDD Ansatz das gewisse Etwas, ein ganzheitlicher Ansatz der zur Qualität der Software beiträgt.
BDDs tragen dazu bei, dass die Software die Minimal Requirements erfüllt werden und das bei einer sehr hohen Qualität, was den Code betrifft.
Beim TDD-Ansatz wird so vorgegangen. Zuerst schreibt man den Test, der das zu implementierende Feature ausgiebig testet. Wenn der Test fertig ist, wird das Feature implementiert, aber gerade nur so viel, sodass der Test grün wird.
So gut auch TDD klingt, es hat gegenüber BDD doch einen Nachteil. Der Hauptgrund ist, dass TDD Tests eher Unit Tests sind, die mit dem eigentlichen Feature sehr eng verbunden sind. TDD Tests fokussieren sich mehr an der Methode, als an dem Gesamtfeature. Zudem führt das auch dazu, dass man den Test umbenennen oder sogar umschreiben muss, sobald sich die Implementierung des Features ändert.
Fazit:
BDD sollte in jedem Unternehmen eingesetzt werden, die leicht wartbare und ausführlich dokumentierte Software entwickeln wollen. Der BDD Ansatz ist so genial und so einfach handzuhaben, dass es schon leicht fahrlässig ist, wenn man BDDs nicht einsetzt.
Auf Pinterest folgen
