Ihr Chef wird TDD nicht zu schätzen wissen: Probieren Sie dieses Beispiel für eine verhaltensgesteuerte Entwicklung aus

Testen. Es bleibt oft bis zur letzten Minute übrig und wird dann gekürzt, weil Sie keine Zeit mehr haben, das Budget überschreiten oder was auch immer.

Das Management wundert sich, warum Entwickler es nicht gleich beim ersten Mal richtig machen können, und Entwickler (insbesondere bei großen Systemen) überrascht werden können, wenn verschiedene Beteiligte verschiedene Teile des Systems beschreiben, wie die Geschichte der Blinden, die eine beschreibt Elefant.

Es ist jedoch unvermeidlich, dass der erste Schritt in jedem Projekt eine Diskussion über das Verhalten der zu erstellenden Software oder Funktion ist. Ein Kunde oder eine Geschäftsperson kommt zu jemandem aus dem Entwicklungsteam und erklärt, was er möchte.

Manchmal kommen diese Interaktionen in Form einer Agile User Story. Manchmal liegen sie in Form von Designdokumenten vor, wie im Blogeintrag von Chris Fox im vergangenen Jahr. Sie könnten auch als Flussdiagramme oder Mockups in Keynote oder sogar als eilige Telefonanrufe erscheinen.

Allein aufgrund dieser Kommunikation ist ein Entwickler dafür verantwortlich, ein System zu konstruieren, das „einfach funktioniert“. Dies ist besonders schwierig für Freiberufler, die außerhalb des größeren Systems arbeiten.

Warum wird das Testen gekürzt?

Hier gibt es eine offensichtliche Lücke: Wenn der Geschäftsinhaber sich das Verhalten des Systems zu Beginn vorgestellt hat, warum ist das Testen, ob dieses Verhalten tatsächlich funktioniert , oft der Schritt, der gekürzt wird?

Die Antwort mag verblüffend einfach sein: Tests werden oft nicht als gemeinsames Kapital angesehen; Sie werden nicht als wertvoll für das Projekt angesehen, weil „sie nur für die Ingenieure sind“ oder in ähnlicher Weise einer einzelnen Abteilung oder Gruppe von Menschen einen Mehrwert bieten.

Wie testen wir dieses gemeinsame Kapital, diese Liste von Systemverhalten? Indem wir nicht nur die testgetriebene Entwicklung (TDD), sondern auch die verhaltensgetriebene Entwicklung (BDD) einbeziehen.

Was ist BDD?

Die verhaltensgesteuerte Entwicklung sollte sich auf das Geschäftsverhalten konzentrieren, das Ihr Code implementiert: das „Warum“ hinter dem Code . Es unterstützt einen teamzentrierten (insbesondere funktionsübergreifenden) Workflow.

Ich habe gesehen, dass agiles BDD wirklich gut funktioniert, wenn ein Entwickler und entweder der Agile-Produktbesitzer oder ein Geschäftsanalyst sich zusammensetzen und ausstehende Spezifikationen (die später vom Entwickler ausgefüllt werden) in einem einfachen Texteditor schreiben:

1. Die Geschäftsperson gibt Verhaltensweisen an, die sie im System sehen möchte.
2. Der Entwickler stellt Fragen basierend auf seinem Verständnis des Systems und schreibt gleichzeitig zusätzliche Verhaltensweisen auf, die aus Entwicklungsperspektive erforderlich sind.

Im Idealfall können beide Parteien anhand der Liste der aktuellen Systemverhalten nachsehen, ob diese neue Funktion vorhandene Funktionen beeinträchtigt.

Ich habe festgestellt, dass diese einfache Handlung mir genügend Einschränkungen gibt, damit ich wie ein Entwickler denken kann: „Angesichts der Tatsache, dass ich diese Tests implementieren muss, wie zwingt mich das/jeden in eine Spezifikation, die ich in Code implementieren kann“? Da es sich um ausstehende Spezifikationen handelt, können sie schnell und einfach mitten in der Zusammenarbeit geschrieben werden.

Dieser kollaborative Ansatz ermöglicht es mir, mich auf das zu konzentrieren, was die Funktion dem Endbenutzer bietet, und die Tatsache, dass die Geschäftsperson direkt vor Ort ist, zwingt mich, über das Verhalten und nicht über die Implementierung zu sprechen. Dies hebt die Unterschiede zwischen BDD und TDD hervor.

Sehen wir uns ein Beispiel für verhaltensgesteuerte Entwicklung an

Das Szenario: Sie sind Entwickler in einem Team, das für das in Rails implementierte Buchhaltungssystem des Unternehmens verantwortlich ist. Eines Tages bittet Sie ein Geschäftsmann, ein Erinnerungssystem zu implementieren, um Kunden an ihre ausstehenden Rechnungen zu erinnern. Weil Sie BDD gemäß dieser Anleitung üben; (im Gegensatz zu TDD) setzen Sie sich mit dieser Geschäftsperson zusammen und beginnen, Verhaltensweisen zu definieren.

Sie öffnen Ihren Texteditor und beginnen mit der Erstellung ausstehender Spezifikationen für die Verhaltensweisen, die der Geschäftsbenutzer wünscht:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Dieser Fokus auf das Verhalten während der Entwicklung macht den Test nützlich, um zu überprüfen, ob Sie das richtige Feature erstellen, und nicht nur, ob Ihr Code korrekt ist. Beachten Sie, dass die Formulierung in der Geschäftssprache und nicht in der internen Implementierungssprache des Systems erfolgt. Sie sehen oder kümmern sich nicht darum, dass eine Rechnung belongs_to einem Konto gehört, weil sich niemand außerhalb des Entwicklungsteams darum kümmert.

Einige Entwickler ziehen es vor, Testfälle vor Ort zu schreiben, Methoden im System aufzurufen und Erwartungen aufzustellen, wie folgt:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

Die Testsuite wird fehlschlagen, da wir noch den Code zum Festlegen von " reminder_date " schreiben müssen.

Angesichts fehlerhafter Spezifikationen

Ich verstehe Entwickler, die fehlerhafte Spezifikationen schreiben, aber mit der Geschäftsperson an meiner Seite hat das für mich nie funktioniert. Die falsche Geschäftsperson wird sich entweder von den Details ablenken lassen oder dieses neue Wissen nutzen und versuchen, Dinge im Mikromanagement zu verwalten, über die der Entwickler mehr weiß (korrektes Datenbankdesign, Wiederverwendung von Code).

Meiner Erfahrung nach wird es die Geschäftsperson langweilen, mehr als eine einzeilige Übersicht über ein bestimmtes Verhalten zu schreiben. Sie werden es als schlechte Nutzung ihrer Zeit ansehen oder ängstlich darauf bedacht sein, das nächste Verhalten zu beschreiben, während es ihnen in den Sinn kommt.

Wie unterscheidet sich BDD von TDD?

Betrachten wir dies mit einem Test-Driven-Development-Ansatz aus einer anderen Perspektive und schreiben ausstehende Tests auf:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Diese Tests sind hilfreich, aber nur für eine Personengruppe hilfreich: Ingenieure. BDD ist nützlich für die Kommunikation mit jedem Mitglied eines funktionsübergreifenden Produktteams.

Sie können sicherlich eine Test-First-Entwicklung durchführen, während Sie in einer BDD-Denkweise sind, indem Sie ausstehende Verhaltensweisen verwenden. Schreiben Sie zuerst den Test; dann führe es aus (rot); dann lass es funktionieren (grün); dann machen Sie es richtig (Refaktor).

In der BDD-Community wurde viel Arbeit darauf verwendet, die Assertion-Checks im Test wie Englisch zu lesen. Hier ist ein stereotyper RSpec-Test:

 a = 42 a.should == 42

Dieses Format erleichtert später das Lesen. Aber denken Sie daran, das ist nicht das, was wir hier tun – es geht darum, Verhaltensweisen so schnell wie möglich abzubauen – und das Prinzip „ein getestetes Verhalten pro Spezifikation“ durchzusetzen. Im Idealfall sollte Ihnen der Titel der ausstehenden Spezifikation sagen, was Sie testen.

Bei BDD geht es nicht um ausgefallene Möglichkeiten, Ihre Ergebnisse zu validieren; Es geht darum, erwartete Verhaltensweisen mit allen Teammitgliedern zu teilen.

Bei der verhaltensgesteuerten Entwicklung geht es um Zusammenarbeit und Kommunikation

Kehren wir zu unserem Szenario zurück: Arbeiten am Buchhaltungssystem des Unternehmens.

Sie gehen mit der Geschäftsperson die Funktionalität des Artikels durch, wobei Sie das System anhand seiner Interna analysieren (wie die Objekte intern zusammenpassen) und sie das System von außen analysieren.

Sie denken an einige Bedingungen und fragen den Business-Analysten, was in den folgenden Szenarien passiert:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Und Sie bekommen Antworten . Es ist wichtig, dass die Geschäftsperson versteht, dass Sie nicht versuchen, Löcher in ihre Lieblingsidee zu schlagen oder übermäßig pedantisch zu sein.

Auf diese Weise ist die verhaltensgesteuerte Entwicklung ein Werkzeug, um die Zusammenarbeit zu unterstützen und ein Gespräch zwischen den beiden Abteilungen zu beginnen. Es ist auch eine Möglichkeit, den Umfang einer gewünschten Funktion zu verdeutlichen und bessere Schätzungen vom Entwicklerteam zu erhalten. Vielleicht stellen Sie fest, dass es keine Möglichkeit gibt, 10 Werktage ab einem bestimmten Zeitpunkt zu berechnen; das ist eine zusätzliche, separate Funktion, die Sie implementieren müssen.

Entwickler haben Entwicklerüberlegungen („Was genau meinen Sie, wenn Sie „Tag“ sagen?“), während Geschäftsleute ihre eigenen Überlegungen haben („Bitte verwenden Sie hier nicht den Begriff überfällig, das bedeutet etwas anderes“). Wenn die eine oder andere Gruppe losgeht und versucht, diese Geschäftslogik-Verhaltenstests selbst zu schreiben (das Versprechen von Cucumber), schneidet den wertvollen Input jeder Seite ab.

Es ist auch ein guter Ersatz, wenn der Agile Client nicht mehr physisch im Raum ist: seine Wünsche auf Papier zu haben, gemischt mit Entwickleranalyse (und Übersetzung) dessen, was Sie bauen.

Design-Dokumente

In einem früheren Toptal-Blogbeitrag spricht Chris Fox über Designdokumente, insbesondere zu Beginn eines Projekts. Das Verständnis und Extrahieren des Geschäftsverhaltens reicht von Projekten, bei denen das System einigermaßen bekannt ist, bis hin zu Projekten, die Jahrzehnte von Programmierjahren erfordern, um sie zu erreichen, und die Hunderte oder Tausende von Verhaltensspezifikationen haben.

Der Artikel von Chris erwähnt auch das Verhalten von Elementen auf dem Bildschirm, und dies ist ein Bereich, in dem ich ständig mit Designern uneins bin: „Wie sieht diese Schaltfläche aus, wenn sie abgeblendet ist“ oder „Wie sieht das auf 11“-Bildschirmen aus, weil Diese Seite ist offensichtlich für 24-Zoll-Bildschirme ausgelegt?“ Dieses Hin und Her mit der Geschäftsperson kann Lücken in den Grafikressourcen eines Projekts oder im Layout einer Seite finden.

In sehr großen funktionsübergreifenden Teams gibt es viele Teammitglieder mit eigenen Anliegen: Designer, Entwickler, möglicherweise jemand aus dem Betrieb, der Datenbankadministrator – vielleicht QA-Leute (ja, es gibt einen Platz für alle in TDD und BDD!), jeder mit eigenen Sorgen und Fragen. BDD kann diese Zusammenarbeit stärker vorantreiben als die testgetriebene Entwicklung. Aus "Was passiert, wenn die Daten zu groß für diese Tabelle sind?" zu „Hmmm, das wird eine teure Abfrage, wir wollen das irgendwie zwischenspeichern“ zu „Warte, soll der Benutzer all diese vertraulichen Informationen sehen?“ kann mehr auf dem Spiel stehen als nur ein Entwickler und ein Geschäftsanalyst mit Fragen zu dieser neuen Funktion

Bei der verhaltensgesteuerten Entwicklung geht es um gemeinsame Artefakte

Was ist ein gemeinsames Artefakt?

Ich stelle mir „Artefakte“ im Software-Engineering gerne als potenziell physische Dinge vor, die das Projekt oder das Projektteam beschreiben und sechs Monate später auffindbar sind. Gute Artefakte erklären, warum die Dinge so sind, wie sie sind.

Flurgespräche sind keine Artefakte. Auch keine Whiteboard-Zeichnungen. Whiteboard-Zeichnungen, die in große, lange Unterrichtsdokumentationen oder Designdokumente umgewandelt werden – das sind Artefakte. Auch Sitzungsprotokolle sind Artefakte.

Ein Artefakt ist ein Quellcode, der in einem Repository oder Shared Space gespeichert ist, und Tickets im Ticketsystem oder Notizen im internen Wiki – oder sogar dauerhafte Chat-Protokolle.

Geteilte Artefakte sind meiner Meinung nach die besten Artefakte . Sie zeigen nicht nur, warum etwas so ist, sondern warum es es in der App überhaupt gibt .

Wie verwenden Sie sie in BDD?

Verhaltensweisen sollten ein gemeinsames Team-Artefakt sein – Tests sollten nicht nur fleißige Arbeit für Programmierer sein! Während es am besten ist, ein System zu haben, in dem das gesamte Team die aktuellen Spezifikationen leicht einsehen kann (vielleicht extrahiert und speichert das Bereitstellungssystem auch die Liste der Verhaltensweisen in einem privaten Bereich der Website oder einem Wiki), könnten Sie dies auch manuell tun jedes Sprint.

Der Name des Spiels lautet: „Entwicklern helfen, die Spezifikationen zu erstellen, die wir benötigen, um schneller Geschäftswert zu liefern, abteilungsübergreifend zusammenzuarbeiten und bessere Schätzungen vorzunehmen“.

Dieses unternehmensweite Verständnis dessen, was das System tut , ist auch eine Form von Kapital. Es ist das „Warum“ zum „Wie“ des Codes.

Fazit

Wie lösen wir das Problem fehlerhafter Software, die an Kunden geliefert wird? Indem sichergestellt wird, dass das Testen nicht als etwas betrachtet wird, „um das sich nur die Entwickler kümmern“.

Das Beschreiben und Verstehen der Anforderungen eines Systems hat eine Menge Vorteile, die über die Korrektheit des Codes hinausgehen: den Aufbau eines abteilungsübergreifenden Dialogs und die Sicherstellung, dass alle Anliegen der Stakeholder berücksichtigt werden (und nicht nur die Stakeholder mit großen, ausgefallenen Titeln). Verwenden Sie verhaltensgesteuerte Entwicklung, um diese Anforderungen von Anfang an zu verstehen, und testen Sie externe Geschäftsverhaltensweisen, die dem gesamten Team wichtig sind – das ist eine großartige Möglichkeit, ein qualitativ hochwertiges Projekt sicherzustellen.