Testgetriebene Entwicklung ist eine Test-First-Softwareentwicklungsmethode, bei der Testcode geschrieben werden muss, bevor der eigentliche Code geschrieben wird, der getestet werden soll. In Kent Becks Worten:
Der Stil hier besteht darin, ein paar Codezeilen zu schreiben, dann einen Test, der ausgeführt werden sollte, oder noch besser, einen Test zu schreiben, der nicht ausgeführt werden soll, und dann den Code zu schreiben, der ihn ausführen lässt.
Nachdem wir herausgefunden haben, wie man ein kleines Stück Code schreibt, möchten wir jetzt, anstatt nur weiter zu codieren, sofortiges Feedback erhalten und üben, "ein wenig zu codieren, ein wenig zu testen, ein wenig zu codieren, ein wenig zu testen". Also schreiben wir sofort einen Test dafür.
TDD ist also eine einfache technische Methode, mit der Programmierer sauberen Code erstellen, der funktioniert.
Behavior-Driven Development ist eine Methodik, die auf TDD basiert, sich jedoch zu einem Prozess entwickelt hat, der nicht nur Programmierer und Tester betrifft, sondern sich mit dem gesamten Team und allen wichtigen technischen und nichttechnischen Stakeholdern befasst. BDD begann mit ein paar einfachen Fragen, die TDD nicht gut beantwortet: Wie viele Tests sollte ich schreiben? Was soll ich eigentlich testen - und was soll ich nicht? Welche der Tests, die ich schreibe, sind tatsächlich wichtig für das Geschäft oder die Gesamtqualität des Produkts, und welche sind nur meine Überentwicklung?
Wie Sie sehen, erfordern solche Fragen die Zusammenarbeit zwischen Technologie und Unternehmen. Geschäftsinteressenten und Domain-Experten können Ingenieuren häufig sagen, welche Art von Tests nützlich erscheinen - aber nur, wenn es sich bei den Tests um Tests auf hoher Ebene handelt, die sich mit wichtigen Geschäftsaspekten befassen. BDD nennt solche geschäftsmäßigen Tests „Beispiele“ wie in „Nennen Sie mir ein Beispiel für das korrekte Verhalten dieser Funktion“ und reserviert das Wort „Test“ für technische Überprüfungen auf niedriger Ebene wie Datenvalidierung oder Testen von API-Integrationen. Der wichtige Teil ist, dass Tests zwar nur von Programmierern und Testern erstellt werden können, Beispiele jedoch vom gesamten Bereitstellungsteam gesammelt und analysiert werden können - von Designern, Analysten usw.
In einem Satz ist eine der besten Definitionen von BDD, die ich bisher gefunden habe , dass es bei BDD darum geht, „Gespräche mit Domain-Experten zu führen und anhand von Beispielen ein gemeinsames Verständnis des gewünschten Verhaltens zu erlangen und Unbekanntes zu entdecken“. Der Entdeckungsteil ist sehr wichtig. Je mehr Beispiele das Lieferteam sammelt, desto mehr verstehen sie den Geschäftsbereich und verringern so die Unsicherheit über einige Aspekte des Produkts, mit dem sie sich befassen müssen. Mit abnehmender Unsicherheit nehmen Kreativität und Autonomie des Lieferteams zu. Zum Beispiel können sie jetzt ihre eigenen Beispiele vorschlagen, die die Geschäftsanwender aufgrund ihres Mangels an technischem Fachwissen nicht für möglich hielten.
Gespräche mit Geschäfts- und Domain-Experten zu führen, klingt großartig, aber wir alle wissen, wie oft dies in der Praxis endet. Ich habe meine Reise mit Technik als Programmierer begonnen. Als Programmierer lernen wir , Code zu schreiben - Algorithmen, Entwurfsmuster, Abstraktionen. Oder wenn Sie Designer sind, wird Ihnen das Entwerfen beigebracht- Informationen organisieren und schöne Schnittstellen erstellen. Aber wenn wir unsere Einstiegsjobs bekommen, erwarten unsere Arbeitgeber von uns, dass wir "den Kunden einen Mehrwert bieten". Und unter diesen Kunden kann zum Beispiel ... eine Bank sein. Aber ich konnte so gut wie nichts über Bankgeschäfte wissen - außer wie ich meinen Kontostand effizient senken kann. Also müsste ich irgendwie das, was von mir erwartet wird, in Code übersetzen ... Ich müsste eine Brücke zwischen dem Bankgeschäft und meinem technischen Know-how schlagen, wenn ich irgendeinen Wert liefern will. BDD hilft mir dabei, eine solche Brücke auf einem stabilen Fundament der fließenden Kommunikation zwischen dem Lieferteam und den Domain-Experten zu bauen.
Mehr erfahren
Wenn Sie mehr über BDD lesen möchten, habe ich ein Buch zu diesem Thema geschrieben. In „Schreiben großartiger Spezifikationen“ wird die Kunst des Analysierens von Anforderungen untersucht und Sie lernen, wie Sie einen großartigen BDD-Prozess erstellen und Beispiele als Kernbestandteil dieses Prozesses verwenden. Das Buch spricht über die allgegenwärtige Sprache, das Sammeln von Beispielen und das Erstellen sogenannter ausführbarer Spezifikationen (automatisierte Tests) aus den Beispielen - Techniken, die BDD-Teams dabei helfen, großartige Software pünktlich und im Rahmen des Budgets bereitzustellen.
Wenn Sie sich für den Kauf von „Writing Great Specifications“ interessieren, können Sie mit dem Promo-Code 39nicieja2 39% sparen :)