TFS ist eine feste Marktgröße

Dennoch ist es Fakt, dass der TFS eine feste Position im Markt einnimmt. Man mag jetzt alle möglichen Gründe für diesen Umstand anführen. Ich persönlich denke dass einer der Hauptgründe für den (relativ) breiten Markteinsatz von TFS schlicht und einfach die Bequemlichkeit des Unternehmens (also TFS-Kunden) ist. Wie dem auch sei, der TFS ist da. Ich finde das auch gut so. Jedem das seine.

Sowie vor dem Hintergrund der Präsenz von TFS als auch aus Eigeninteresse ist es für mich dennoch interessant zu wissen, ob und wie sich TFS 2010 mit meinem Toolset anwenden lässt. Jürgen hatte ja schon über die Nachteile von TFS TeamBuild gebloggt. Dem kann ich mich widerspruchsfrei und vollends anschließen. Er merkte z.B. an, dass Team Build sehr schwer mit alternativen Test-Frameworks in Gang zu bringen ist. Richtig – aber es geht. Ich möchte das einmal für MSpec (die Machine.Specifications) vorstellen.

MSpec & TFS: Die Schöne und das Biest

Es gibt einen exzellenten Blog-Post von DoD über den Einsatz von MSpec mit dem TFS 2010 Team Build. Auf Basis dieses Blog-Posts habe ich es auch geschafft, den MSpec-Runner in den Team Build zu integrieren.

Zunächst einmal ist es notwendig, sich die einzelnen Komponenten, also das MSpecBuildTemplate-XAML und den angepassten NUnitTFS-Code zu besorgen (am Ende des Blog-Posts von DoD). Der nächste Schritt ist es, den NUnitTFS-Code zu kompilieren und gleichzeitig die MSpecToMSTest.xslt Datei auf den Build-Server zu verfrachten. Achtung: MSpecToMSTest.xslt ist im Source-Code vom gepatchten NUnitTFS begraben (im “NUnitTFS2010” Ordner).

Ich persönlich finde weder den Code noch die Patch-Praxis von DoD schön. Dazu kommt auch noch die zweifelhafte Idee, die XSLT-Templates für die Test-Results-Konvertierung als eingebettete Ressource einzukompilieren. Nun, da ich persönlich diese Lösung sowieso nicht einsetzen werde, überlasse ich das Feld der Optimierungs-Potenziale dem interessierten Leser.

Der nächste Schritt ist es, MSpec mit auf den Buildserver für die Ausführung der Tests zu packen. Für die Testzwecke habe ich beides (also MSpec und NUnitTFS) separat auf den Buildserver gelegt. Bei einem echten Projekt würde ich beide Tools mit in die Versionsverwaltung einbringen.

Sind die Tools erst einmal vorbereitet, kann man endlich zur Tat schreiten und das BuildTemplate im TFS installieren. Bequem in Visual Studio, so wie es sich gehört. Nach dem man das Template zu den BuildProcessTemplates hinzugefügt hat, kann man es auch über die Build Config auswählen. Die Einstellungen sind relativ schnell und einfach gepflegt. Wichtig ist dabei nicht nur da korrekte setzen der Tool-Pfade, sondern auch die Angabe der Buildkonfiguration (z.B. Any CPU|Debug).

Ok. Team Build kann auch anders.

Was kann man nun aus diesem kleinen Experiment mitnehmen? Ja ganz einfach: Team Build kann auch ohne MSTest. Man muss eventuell ein wenig Überzeugungsarbeit hineininvestieren, aber es geht. Im Übrigen ist es auch interessant zu wissen, dass es nicht nur ein angepasstes XAML-BuildTemplate für MSpec gibt, sondern auch für XUnit und natürlich NUnit, denn schließlich ist der Name des auf Codeplex gehosteten Tools nicht umsonst NUnitTFS.

Fazit: Team Build kann auch anders. Aha. Gut – interessant zu wissen. Schönen Dank auch.