Als absoluten Vorteil von BDD empfinde ich die Möglichkeiten die es bei der technischen Dokumentation bietet. Denn sind wir doch mal ehrlich, die einzige Wahrheit steckt doch im Code und herkömmliche Doku lügt uns nur all zu schnell an.
Schreibe ich beispielsweise eine Funktion mit der die Daten der letzten 12 Monate ausgewertet werden, stimmen Dokumentation und Implementierung noch überein. Verlangt mein Kunde aber eine Woche später, dass nur noch 6 Monate ausgewertet werden sollen, ist die Änderung im Code minimal wobei die Anpassung in der Spezifikation und Dokumentation unter Umständen viel aufwändiger wird, ganz einfach weil man mehrere Dokumente zu pflegen hat.
Allein die Tatsache, dass man ein anderes Programm öffnen muss sorgt schnell dafür, dass man solcherlei Anpassungen gern etwas aufschiebt um sich nicht im Arbeitsfluss stören zu lassen und hat man erst einmal etwas aufgeschoben wird dies auch teilweise vergessen. Die Auswirkungen dessen muss ich wohl niemandem erläutern…
Mit BDD und vor allem Specflow ist das anders. Hier würde im Gherkin File einfach die 12 zur 6 gemacht und damit ist die Dokumentation dem Code sogar ein Schritt voraus und was noch viel wichtiger ist, es wird automatisch angezeigt, dass die Anpassung noch nicht vorgenommen wurde.
Das ist aber nicht der einzige Vorteil. Denn tatsächlich kann man dieses „Verhalten“ auch als eine Art Fortschrittsanzeige verstehen, denn Specflow zeigt uns ja nicht nur welche Bereiche der Software nicht mehr funktionieren, sondern auch welche noch gar nicht begonnen wurden oder schon abgeschlossen sind.
Die Berichte
Der Schlüssel dazu ist der Execution Report. Er zeigt auf einen Blick was alles funktioniert, gerade nicht so recht will oder der Erledigung harrt. Nachfolgend sieht man zwei Ausgaben des Reports für ein Spielprojekt von mir. Darin kann man den Projektfortschritt schon in der ersten Zeile sehr gut sehen.
Da die Auswertung immer auf Basis eines Testlaufs erstellt wird, ist es zur Zeit leider nicht möglich zeitliche Veränderungen anzuzeigen, wodurch ein Burndownchart u.ä. wohl vorerst ein Wunschtraum bleibt.
Der zweite Bericht im Bunde ist der Stepdefinition Report. Mit ihm kann man den Überblick über die schnell zahlreicher werdenden Schrittmethoden behalten. Denn er zeigt deren Aufrufe samt verwendeter Daten an.
Ganz interessant ist hierbei vor allem die Anzahl der Aufrufe, über welche man nicht benötigte Methoden schnell aufspüren kann, und die Möglichkeit aus dem Bericht heraus sogar gleich zu ermitteln in welchen Featuredateien und dort in welchen Zeilen der Schritt aufgerufen wird.
Probleme und Herausforderungen
Will man die Berichte aber nun erstellen, hat man zunächst mit einem kleinen „Problem“ zu kämpfen: So werden die Reports über die Specflow.exe aus dem Installationsverzeichnis von Specflow und nicht direkt aus Visual Studio heraus erstellt.
Aus diesem muss man für die Generierung der Berichte ein wenig Hand anlegen. Das entsprechende Vorgehen dazu wurde einmal hier für NUnit und dann auch hier für MS Test beschrieben. Da ich Specflow aber in zwei Projekten nutze die jeweils eines der beiden Frameworks verwenden und ich neben dem Execution auch den Stepdefinition Report erstellt haben möchte, habe ich mir auf Basis dessen eine eigene Lösung gebastelt.
Diese Batch-Datei kann recht einfach aus dem Visual Studio heraus aufgerufen werden indem unter Tools -> External Tools ein entsprechender Dialog aufgerufen und dort folgende Daten eingetragen werden.
Title: Name des Menüeintrags der später im Tools Menü auftaucht
Command: Pfad zur Batch-Datei (sollte am besten im Installationsverzeichnis von Specflow liegen)
Arguments: Parameter der Batch
Initial Directory: $(BinDir) (also das „bin“ Verzeichnis des Projekts)
Der erste Parameter bestimmt dabei welcher Bericht erstellt werden soll, dabei kann zwischen Execution, Steps und All gewählt werden wobei letzteres beide Reports erstellt und danach anzeigt.
Der zweite Parameter bestimmt das Framework und muss immer entweder NUnit oder MSTest (zusammengeschrieben!) lauten. Andere Frameworks werden nicht unterstützt.
Als dritter Parameter folgt dann der Pfad zur Projektdatei in der die Spezifikationen liegen $(ProjectDir)$(ProjectFileName). Da mit diesen Variablen immer das aktuell im Solution Explorer ausgewählte Projekt verwendet wird, muss also bei der Ausführung auch jenes selektiert sein!
Als vierter Parameter, der nur bei MS Test gebraucht und somit bei NUnit nicht angegeben werden muss, folgt noch der Pfad zur Dll mit den Spezifikationen. $(TargetName)$(TargetExt)
Daraus ergibt sich zum Beispiel folgende Argumentenliste:
All MSTest $(ProjectDir)$(ProjectFileName) $(TargetName)$(TargetExt)
Unter Umständen gibt es nun aber immer noch Probleme. Denn in der Batch verwende ich ein paar Standardpfade. Ist zum Beispiel NUnit nicht unter folgendem Pfad installiert, sollte dieser in der Batch angepasst werden.
%ProgramFiles(x86)%\NUnit 2.5.10\bin\net-2.0\nunit-console.exe
Gleiches gilt auch für MS Test welches auf folgenden Pfad konfiguriert ist:
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe
Last but not least, kann man mit .Net 4.0 noch in eine andere Falle tappen wenn der Stepdefinition Report erstellt werden soll. Da Specflow mit .Net 3.5 kompiliert wird/wurde erscheint in diesem Fall folgende Meldung: „Die Datei oder Assembly „…“ oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.“
In dem Fall muss einfach eine Datei Namens specflow.exe.config im Installationsverzeichnis von Specflow hinterlegt werden die folgenden Inhalt hat und somit dafür sorgt, dass das Framework die passende Version nutzt.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
</configuration>
Specflow Reporting Batch File (201)
Kommentare