Specflow

29. September 2015

Mit “Specflow – Binding business requirements to .NET code” begrüßte mich eine Artikelüberschrift in einer Entwicklerzeitschrift. Hierbei kamen für mich mehre interessante Aspekte, wie die Abbildung von fachlichen Anforderungen, automatisierbare Testfälle und Codegeneratoren zusammen. Laut eigener Aussage wurde das zugrundeliegende Framework auf über 40 Programmiersprachen implementiert. Meine Neugier war geweckt.

Specflow ist eine von vielen Umsetzungen von Behaviour Driven Development (BDD). Hierbei sollen die Stakeholder, bzw. die Product Owner mehr in die Implementierung einbezogen werden, um das Produkt, die Software, mehr auf den fachlichen Nutzen zu fokussieren. Bei BDD handelt es sich um eine Erweiterung von Test Driven Development (TDD). Bevor also ein Feature umgesetzt wird, werden Testfälle geschrieben. Bei BDD von der Fachseite. Sie definiert ihre Fachanforderungen in einer allgegenwärtige Sprache, auch Ubiquitous Language oder Domain Specific Language (DSL) genannt. Wie im Bild dargestellt wird dann aus dieser Definition über ein Framework Code generiert.
Specflow ist eines von vielen Cucumber Frameworks, die auf der Sprache Gherkin aufsetzen. Ursprünglich hat alles mit Ruby angefangen, heute werden neben C# auch viele andere Sprachen bedient.

DSL

Gherkin und Cucumber beziehen sich auf das Wort “Gurke”, Gurkengrün oder passend übersetzt Grasgrün und soll auf den gewünschten finalen grünen Status der Testfälle anspielen. Die fachlichen Anforderungen werden als Features in Szenarien zerlegt. Jedes Szenario führt zu einem Akzeptanztest. Diese können in Testrunnern, wie MSTest oder NUnit ausgeführt werden.

Cucumber Szenario

Specflow generiert hieraus eine C# Testklasse, die man noch mit Leben füllen muss. Es erstellt lediglich die Klasse samt Methoden und führt den Aufruf zur Laufzeit durch.

Klassengerüst

Das fast komplette “Getting Started” Beispiel findet sich auf Specflow.org. Lediglich die Anpassungen der App.config fehlen, hier muss angegeben werden für welche Testrunner man die Tests erzeugt haben möchte:

   1: <unitTestProvider name="MSTest" />

   2: oder

   3: <unitTestProvider name="NUnit" />

   4: oder

   5: ...

Als Entwickler kann ich nur implementieren, was ich verstanden habe. Für mich ist dies immer der Haken an TDD, denn auch meine Tests spiegeln nur mein Wissen wieder. Auf der einen Seite begegnen mir heute riesige Fachdokumente und auf der anderen “War doch klar” Aussagen. Nichts ersetzt die direkte Kommunikation, denn auch Anforderungen präzisieren sich meist erst beim Reden und drüber nachdenken. Aber ich denke mit BDD und Cucumber gibt es eine gute Möglichkeit fachliche Anforderungen festzuhalten und besser testbar zu machen.

Die Erfahrungen in solch einem Umfeld zu arbeiten würde ich schon gerne einmal machen.