Als Entwickler im SAP-Umfeld kennt man natürlich auch gängige Praktiken wie Test-driven Development, Pair Programming, usw. allerdings hatte ich mit Behaviour Driven Development bisher noch wenige Entwicklungspunkte. Das wird sich auch sicher mit der vermehrten Entwicklung von Fiori-Anwendungen ändern, da dort auch die Toolunterstützung für die entsprechenden Tests gegeben ist.
Kurz gesagt geht es darum als Entwickler und Tester ein gemeinsames Bild von der Anforderung zu bekommen und den Anfordernden so gut es geht mit einzubeziehen. Das ist natürlich nichts neues. Interessant ist allerdings der Ansatz diese Anforderungen gut ausdrücken zu können und gleichzeitig von der Entwicklung passendes Feedback bezüglich technischer Hürden und Umsetzbarkeit zu bekommen.
Das alles passiert durch Schaffung einer “gemeinsamen Sprache”. Diese gemeinsame Sprache drückt sich durch so viele Experimente wie möglich aus. Diese Experimente zielen auf das erwartete Verhalten ab, daher auch der Name.
Durch Klärung des erwarteten Verhaltens kann dieses auch sehr gut in automatisierte Tests gepackt werden, gegen welche dann entwickelt werden kann. Zudem können sich alle Beteiligten an dem Muster Als … will ich … so dass ich … orientieren um damit anfängliche User Stories zu definieren.
Für die Tests kann dann wiederum das bekannte Given … When … Then … Muster angewendet werden.
Die o.g. Beschreibung der Anforderung wird mittels einer speziellen Sprache definiert. Eine der bekanntesten ist Gherkin.
Der Mehrwert liegt also vor allem in der gemeinsamen Sprache und der ständigen Validierung der Erwartungshaltung durch praktische Beispiele. Ist ein Feature noch nicht umgesetzt kann es auch gerne gemockt werden um trotz dem ein Gefühl zu geben.
Sei der Erste der einen Kommentar abgibt