Vor etwas längerer Zeit habe ich bereits über "TeamCity” als CI Tool geschrieben und wie man MSTest einbinden kann. Im BizzBingo Projekte nutzen wir NUnit und seit TeamCity 6.0 ist Jetbrains dotCover auch direkt mit integriert. Wie das genau aussieht, erfahrt ihr in dem Post.
1. Schritt: Build Configuration anlegen
Der ScreenShot stammt vom Nightly Build und hat eigentlich nix besonders.
2. Version Control Settings
Das müsst ihr je nach Projekt entsprechend einstellen, aber auch hier sind keine Besonderheiten zu beachten. Wir ziehen den Source über die SVN Schnittstelle von Codeplex.
3. Jetzts wird es interessant...
Mein "Nightly” hat 3 Build-Steps, wobei nur zwei hier in diesem Blogpost relevant sind:
- Bau die ganze SLN mit "Rebuild” / "Debug” (hier könnte aber auch ein MSBuild etc. angegeben werden)
- Nimm den NUnit Test Runner und checke die Code Coverage über dotCover
Wir schauen uns genauer den zweiten Schritt genauer an:
NUnit Testrunner Configuration:
Wir haben die NUnit Version 2.5.8 installiert und in der Textbox "Run tests from” ist folgendes drin:
%system.teamcity.build.checkoutDir%\Main\Source\BusinessBingo\Tests\*\bin\Debug\*Tests.dll
Da wir die gesamte SLN bauen mit "Debug” wird entsprechend unserem Source Tree die Ergebnisse in den jeweiligen bin Ordnern abgelegt.
Durch Wildcards findet der Runner unsere Tests wie z.B. BusinessBingo.Commandhandler.Tests.dll und führt diese aus.
Wenn wir nun doch noch neue Test Projekte hinzufügen, erscheinen diese automatisch mit im Build - "Convention over Configuration”.
Nun laufen die Unit Tests... nun zu dotCover.
Im neusten TeamCity 6.0 ist dotCover direkt mit eingebaut, d.h. man braucht keine dotCover Installation auf dem Buildserver vornehmen. Die Konfiguration ist sehr simpel gestaltet:
Durch die Filter, weißt man dotCover an welcher Code beim UnitTesting für die CodeCoverage auch beachtet werden soll.
+:BusinessBingo.* -:BusinessBingo.*Test*
Wichtig hier: Kein ".dll” angeben, sondern nur den Namen. Mit "+” sagt man: Untersuche Assemblies mit diesem Namensschema (auch hier gehen Wildcards) und mit "-" sage ich, dass dort keine CodeCoverage beachtet werden soll.
Kleiner Tipp noch: Falls alles richtig gemacht wurde, aber kein Report geniert wird - schaut ins BuildLog. Am Anfang gab es bei mir solch einen Fehler:
Failed to read source file 'C:\TeamCity\buildAgent\temp\buildTmp\dotcover8583844779204955574.xml'. Could not find a part of the path 'C:\Windows\system32\config\systemprofile\AppData\Local\Temp\4q-kqg6z.tmp'.
Lösung davon:
Unter "C:\Windows\system32\config\systemprofile\AppData\Local\” den gesuchten "Temp” Ordner anlegen - der existiert im Standardfall nicht und scheinbar gibt es da Probleme. Danach geht es aber und läuft stabil.
Was hat man nun?
Schicke Unit-Tests, welche nun auch vom Buildserver ausgeführt werden:
Code Coverage für die angegebenen Assemblies:
Hier kann man bis auf die .cs Datei reinschauen, was genau durchlaufen wird oder nicht:
Sowie eine nette, kleine Übersicht:
Fetzt und ist in kurzer Zeit eigentlich für die einfachsten Zwecke eingerichtet.
