Integration von SpecFlow Reports mit NUnit 3 in TeamCity

Nachdem wir in einem Projekt angefangen haben, SpecFlow für Integrations- und Systemtests einzusetzen, wollten wir SpecFlow Reports in unserer Build Pipeline integrieren. Unsere Builds laufen auf TeamCity 10, dabei verwenden wir NUnit in Version 3 als Testtreiber. Aktuell bietet SpecFlow keine direkte Unterstützung zur Erstellung von Reports aus dem Test-Ergebnis von NUnit 3. Zum Glück kann ich euch in diesem Beitrag zeigen, wie man die Reports dennoch mit Hilfe von den NUnit Command Line Options erstellen kann.

Für die vollständige Lösung werden zunächst die Unit Tests in TeamCtiy ausgeführt unter Verwendung des NUnit3 Runners. Anschließend wird ein zusätzlicher Build Step angewendet, um aus der Datei mit dem Test-Ergebnis einen Report zu erstellen und diesen als Artefakt zu speichern. Ein Bonus kann erzielt werden, wenn man einen zusätzlichen Build Tab zur Anzeige des Reports konfiguriert. Voraussetzung für die Umsetzung ist ein ansonsten bereits lauffähiger Build (z.B. bereits existierende Build Steps für NuGet und Build/Visual Studio).

NUnit3 Build Step

Erstelle einen neuen Build Step in der TeamCity Build Configuration. Wähle „NUnit“ als „Runner Type“ und „NUnit3“ als „NUnit runner“. Jetzt muss der „Path to NUnit console tool“ festgelegt werden. Da wir NuGet nutzen, um diese Abhängigkeit zu laden, können wir folgenden Pfad angeben: „packages\NUnit.ConsoleRunner.3.4.1\tools\nunit3-console.exe“. Du solltest das entsprechend an deine Umgebung anpassen, wie die richtige NUnit-Version, die ihr einsetzt. Im Feld „Run Tests from“ können nun alle dlls runtergeschrieben werden, die für die Tests ausgeführt werden sollen, hier insbesondere die dlls, welche die SpecFlow Tests enthalten. Darum sind wir ja hier. Damit sollte jetzt die Testausführung funktionieren.

Der wichtigste Teil fehlt noch. Als „Additional command line parameters“ muss noch folgendes eingetragen werden: „labels=On –result=%teamcity.build.checkoutDir%/SpecFlowTestResult.xml;format=nunit2 –out=%teamcity.build.checkoutDir%/SpecFlowTestResult.txt“. Hiermit wird NUnit mitgeteilt, dass das Ausgabeformat dem NUnit2-Format entsprechen soll, wie es in SpecFlow benötigt wird.

SpecFlow Report Build Step

Jetzt erstellen wir noch einen weiteren Build Step. Wähle „Command Line“ als „Runner type“ und „Executable with Parameters“ für „Run“. Auch hier gilt, da wir NuGet für unser Dependency Management nutzen, können wir SpecFlow aus dem NuGet „packages“ Ordner heraus starten. Also schreiben wir „packages\SpecFlow.2.1.0\tools\specflow.exe“in das Feld „Command executable“ und folgendes in das Feld „Command parameters“: „nunitexecutionreport your.project.specs\your.project.specs.csproj /xmlTestResult:%teamcity.build.checkoutDir%/SpecFlowTestResult.xml /testOutput:%teamcity.build.checkoutDir%/SpecFlowTestResult.txt /out:%teamcity.build.checkoutDir%/SpecFlowTests.html“.Verweise hierbei auf die Dateien, die vorher durch den NUnit3 Build Step erzeugt wurden und definiere den Pfad zum entsprechenden SpecFlow-Projekt innerhalb deiner Solution Ordner Hierarchie. Damit wird der SpecFlow Report erstellt und in die Datei „SpecFlowTests.html“ geschrieben.

Buld Artifact

Um erstellte Output Dateien dauerhaft zu speichern, muss im „General Settings“ Tab deiner Build Configuration eine zusätzliche Zeile „SpecFlowTests.html“ (und wenn du möchtest auch die anderen beiden erstellten Test-Ergebnis-Dateien“ in das Feld „Artifact paths“ eingetragen werden. Nach der Ausführung der Build Configuration, kann jetzt die „SpecFlowTests.html“-Datei geöffnet werden, diese wird unter „artifacts ouput“ gelistet.

SpecFlow Report Tab

Navigiere in die „Project Settings“ und klicke auf „Report Tabs“. Erstelle hier einen neuen Tab durch Klick auf den Button „Create new build report tab“. Wähle „SpecFlowReport“als „Tab title“ und „SpecFlowTests.html“ als „start page“. Du kannst auch zusätzlich einen Project Report tab hinzufügen, hier musst du lediglich noch die Build Configuration angeben, aus der die Datei geladen werden soll.

Das Ergebnis

Jetzt ist die Arbeit erledigt, also können wir uns das Ergebnis einmal anschauen. Hier ist ein Screenshot aus unserer Pipeline, der die Funktionalität im Einsatz zeigt.

Dieser Blogpost wurde ebenfalls auf meinem persönlichen Blog in englischer Sprache veröffentlicht.