Viele haben von Test Driven Development (TDD) sowie Behavior Driven Development (BDD) in Bezug auf die Softwareentwicklung gehört. Nachfolgend sind die Definitionen dieser beiden Praktiken sowie die wichtigsten Unterschiede.

Test Driven Development (TDD)

TDD ist eine Softwareentwicklungstechnik, bei der Entwicklungsteams automatisierte Testfälle schreiben, bevor sie funktionale Teile des Codes schreiben. Dies ist in agilen Methoden beliebt, da es die Lieferung eines versandfähigen Produkts am Ende eines Sprints vorantreibt. Dieser Prozess kann in mehrere Schritte unterteilt werden:

• Ein Entwickler schreibt auf der Grundlage von Anforderungsdokumenten einen automatisierten Testfall, der zunächst fehlschlägt.
• Genau soviel Produktivcode wird implementiert, dass der Test erfolgreich durchläuft.
• Test und Produktivcode werden refaktorisiert.

Testfälle werden meist in Programmiersprachen wie Java, Rubin, etc. geschrieben und können mit Testautomatisierungswerkzeugen wie Selenium, Watir, Windmill, etc. getestet werden. Da man Testskripte in Programmiersprachen schreibt, ist es für einen Business Analysten oder Testverantwortlichen oft schwierig, die Testskripte zu überprüfen.

Behavior Driven Development (BDD)

BDD ist eine Softwareentwicklungstechnik, die das Benutzerverhalten vor dem Schreiben von Testautomatisierungsskripten oder den funktionalen Codeteilen definiert. Dieses Verfahren, stellt sicher, dass es am Ende eines Sprints ein lieferbares Produktinkrement gibt.

• Das Verhalten des Benutzers wird von einem Product Owner/Business Analyst/QA in einfachem Englisch definiert.
• Dies wird dann in automatisierte Skripte umgewandelt, um sie gegen funktionalen Code auszuführen.
• Das Entwicklungsteam beginnt dann mit dem Schreiben des Funktionscodes, um sicherzustellen, dass das automatisiert Testskript ihnen grünes Licht gibt.
• Das Entwicklungsteam kann dann den Code refaktorieren, um am Ende des Sprints ein getestetes Ergebnis zu erhalten.

BDD wird von mehreren Tools wie Cucumber, FitNesse, PowerTools, Docker, etc. gesteuert. Die Testskripte sind im Klartext in Gherkin, Wiki-Frameworks, etc. geschrieben. Da das Verhalten auf Englisch definiert ist, bietet es eine gemeinsame Grundlage für ALLE am Projekt beteiligten Interessengruppen. Dies reduziert das Risiko der Entwicklung von Code, der dem akzeptierten Verhalten des Benutzers nicht stand hält.

Der Unterschied zwischen TDD und BDD

In TDD (Test Driven Development) wird der Test geschrieben, um die Implementierung der Funktionalität zu überprüfen, aber wenn sich der Code weiterentwickelt, können Tests falsche Ergebnisse liefern. BDD (Behavior Driven Development) ist ebenfalls ein Testansatz, unterscheidet sich aber durch das Testen des tatsächlichen Verhaltens des Systems aus Sicht des Endbenutzers.

Test-Design

Sowohl bei TDD- als auch bei BDD-Ansätzen schreibt man Tests vor dem eigentlichen Code. Das Schreiben von Tests hilft zunächst, den Verlauf der Entwicklung vorherzusagen. Die Vermeidung von Fehlern ist das Hauptziel dieser Ansätze. Diese Tests dienen daher auch als konkrete Dokumentation. Um diese Tests schreiben zu können, sind starke Programmierkenntnisse erforderlich. Durch die Programmierung dieser Tests können sie also für den späteren Gebrauch „automatisiert“ werden.

Arbeitsablauf

Der Workflow ist einfach. Entwicklungsteams denken, diskutieren und entwickeln Ideen. Diese Ideen werden in Tests umgesetzt, wobei der erste Test voraussichtlich scheitern wird. Der Code wird später geschrieben, damit der Test bestanden werden kann. Sobald der Test bestanden ist, refaktorisiert man den Code weiter, um schließlich das beste Design zu erhalten. Diesen neu überarbeiteten Code testet man bis zur Fertigstellung des Designs weiter.

Behavior vs. Test

„Worauf testet man?“ ist eine tolle Frage. Testet man, um das Verhalten der Anwendung herauszufinden? Oder testet man die eigentliche Implementierung? Das ist der größte Diskussionspunkt, wenn man über BDD und TDD spricht. In BDD suchet man nach dem Verhalten, z.B. was mit diesem System unter einer bestimmten Bedingung passt. BDD hat in diesem Bereich den Vorteil gegenüber TDD. Da das Verhalten in BDD in einfachem, beschreibendem Englisch geschrieben ist. So können Kunden die Tests verstehen und schneller ihr Feedback geben. Diese offeneren Kommunikationswege ermöglichen es, Feedback besser zu integrieren, um die Tests und das Design der Software weiter zu verbessern. In TDD können nur erfahrene Programmierer den Test verstehen, was natürlich die Kommunikation mit dem breiteren Publikum einschränkt, aber diese Methode liefert Code von höherer Qualität.

Änderungen

Änderungen an der Funktionalität haben weniger Auswirkungen auf BDD im Vergleich zu TDD. BDD ermöglicht es allen Beteiligten, mit den Anforderungen auf Augenhöhe zu sein, was die Akzeptanz im Gegensatz zu TDD erleichtert. Das Verhalten der Anwendung ist die zentrale Idee in BDD. Sie konzentriert sich auf den Kunden und treibt Entwickler und Tester an, in die Fußstapfen des Kunden zu treten. Wenn Aktionen den Endbenutzer nicht betreffen, kann es sein, dass BDD ein solches Szenario nicht sehr gut darstellt, wobei TDD in diesem Fall den Zweck besser erfüllt. Wie bei vielen anderen Softwareentwicklungspraktiken ist es oft nicht möglich, festzustellen, was bei allen Projekten universell funktioniert.

Die Unterschiede zwischen kontinuierlicher Integration, kontinuierlicher Lieferung und kontinuierlicher Bereitstellung einfach erklärt [link]