BDD auf C#: Wie man Tests schreibt, die das Geschäft versteht

BDD auf C#: Wenn Tests die Sprache des Geschäfts sprechen

Stellen Sie sich vor: Sie sind ein C#-Entwickler. Ein Product Owner kommt zu Ihnen und sagt: „Machen Sie, dass der Benutzer nach der Zahlung einer Bestellung eine E-Mail erhält, aber nur, wenn der Betrag mehr als 1000 Rubel beträgt.“ Sie nicken, gehen zum Code, schreiben die Logik, decken sie mit Unit-Tests ab. Eine Woche später zeigen Sie das Ergebnis. Der PO schaut, runzelt die Stirn und sagt: „Ich meinte etwas anderes.“

Kommt Ihnen das bekannt vor? Dies ist das klassische Problem der Kluft zwischen Geschäft und Entwicklung. Und genau das löst BDD auf C# – Behaviour-Driven Development, oder verhaltensgetriebene Entwicklung.

In diesem Artikel werden wir untersuchen, was BDD ist, wie es sich von TDD unterscheidet, und vor allem, wie man BDD in einem C#-Projekt mit SpecFlow und xUnit implementiert. Sie werden echte Codebeispiele sehen, lernen, Szenarien in Gherkin zu schreiben und sie in automatisierte Tests zu verwandeln. Los geht's!

Was ist BDD und warum wird es benötigt?

BDD (Behaviour-Driven Development) ist eine Entwicklungsmethodik, bei der Systemanforderungen durch das Benutzerverhalten beschrieben werden. Anstelle von trockenen technischen Spezifikationen schreiben Sie Szenarien in natürlicher Sprache, die sowohl das Geschäft als auch der Entwickler verstehen.

Die Kernidee von BDD: „Überprüfen Sie nicht, ob der Code funktioniert. Überprüfen Sie, ob sich das System so verhält, wie das Geschäft es erwartet.“

Im Gegensatz zu TDD (Test-Driven Development), bei dem Sie zuerst einen Unit-Test und dann den Code schreiben, konzentriert sich BDD auf Nutzungsszenarien. BDD-Tests sind keine Überprüfung einer Methode oder Klasse, sondern die Überprüfung eines gesamten Benutzerszenarios.

Die drei Säulen von BDD

\n
• Einheitliche Sprache – alle Projektbeteiligten (PO, Analyst, Tester, Entwickler) sprechen dieselbe Sprache. Meistens ist das Gherkin.
\n
• Szenarien – jedes funktionale Element wird durch Given-When-Then (Gegeben-Wenn-Dann) beschrieben.
\n
• Automatisierung – die Szenarien werden in automatisierte Tests umgewandelt, die als Teil der CI/CD-Pipeline ausgeführt werden.
\n

Schauen wir uns nun an, wie das im C#-Code aussieht.

Werkzeuge für BDD auf C#

Für die Implementierung von BDD im .NET-Ökosystem gibt es zwei Hauptwerkzeuge:

\n
• SpecFlow – das beliebteste BDD-Framework für C#. Es parst Gherkin-Szenarien und verknüpft sie mit Code.
\n
• xUnit / NUnit / MSTest – Test-Runner, die die BDD-Tests ausführen.
\n

Wir werden SpecFlow + xUnit verwenden. Die Installation ist einfach – über NuGet:

dotnet add package SpecFlow\ndotnet add package SpecFlow.xUnit\ndotnet add package xunit\ndotnet add package xunit.runner.visualstudio

Erstellen Sie nach der Installation im Projekt einen Ordner Features – dort werden Ihre .feature-Dateien mit den Szenarien leben.

Unser erstes BDD-Szenario in Gherkin schreiben

Gherkin ist eine Sprache zur Beschreibung von Verhalten. Sie verwendet die Schlüsselwörter: Feature, Scenario, Given, When, Then, And, But.

Lassen Sie uns ein einfaches Szenario beschreiben: Ein Benutzer versucht, eine Bestellung zu bezahlen, und wenn der Betrag mehr als 1000 Rubel beträgt, erhält er eine E-Mail.

Erstellen Sie eine Datei Payment.feature im Ordner Features:

Feature: Payment Notification\n    As a customer\n    I want to receive an email after payment\n    So that I have a confirmation of my purchase\n\nScenario: Successful payment over 1000 rubles sends notification\n    Given a customer with balance 5000 rubles\n    When the customer pays an order of 1500 rubles\n    Then the customer should receive an email notification\n\nScenario: Payment under 1000 rubles does not send notification\n    Given a customer with balance 5000 rubles\n    When the customer pays an order of 500 rubles\n    Then the customer should not receive any email notification

Beachten Sie: hier