h1

TFS Team Build: Testen von Webservices mit UnitTests auf dem Client und Team Build Server

Februar 26, 2009

Damit ein UnitTest, den wir gegen einen WebService (z.B. TOService) ausführen auch auf dem Team-Build Server läuft sind folgende Schritte notwendig:

1. Im UnitTest eine WebReference zum Webservice einfügen:

image

2. Im UnitTest folgendes Attribut über der UnitTest-Methode einfügen:

[AspNetDevelopmentServer("TOServiceHost", 
		"%PathToWebRoot%\\Test.TOServiceHost")]

3. In der UnitTest-Methode den WebServiceHelper verwenden:

var sc = new TOService(); 
WebServiceHelper.TryUrlRedirection(sc, 
			TestContext,"TOServiceHost"); 
Assert.NotNull(sc.MyMethodForTest()); 

4. Im Visual Studio unter “Tools” > “Options” > “Test Tools” > “Test Execution” den Pfad eintragen:

Es kann passieren, das auf dem Client der Ordner zum Webservice nicht richtig aufgelöst wird. Dann kann man im VS einstellen, wo der Basisordner (%PathToWebRoot%) liegen soll. Den Ordner, wo der Webservice “Test.TOServiceHost” drin liegt den ihr testen wollt entsprechend einstellen.

image 

5. In der .vsmdi Datei den Test in die Liste eintragen, die im Teambuild ausgeführt wird:

In der VSMDI Datei können dann alle UnitTests der Solution in eine Liste eingefügt werden:

image

Im Teambuild File wird die Liste aus dem VSMDI File angegeben, womit alle UnitTests dieser Liste auf dem Teambuild Server ausgeführt werden:

<MetaDataFile Include=
   "$(BuildProjectFolderPath)/../../Main/Source/Test/test.vsmdi">
   <TestList>AllTests</TestList>
</MetaDataFile>

In der Liste können jetzt auch Tests aufgeführt werden, die einen WebService aus der Solution aufrufen.

6. SolutionFile ggf. bearbeiten:

Wichtig ist, dass der Webservice bzw. die Webapplikation mit auf dem Server compiliert wird. Das kann z.B. über die Solution Configuration “Debug” sichergestellt werden. Wenn hier ein anderer Typ eingeführt wurde (z.B. “Debug_CodeAnalysis”) kann es passieren, dass die Website auf dem Server nicht unter “_PublishedWebsites” kompiliert/abgelegt wird. Dann funktionieren die UnitTests auf dem Server wieder nicht. Es bietet sich an den Solution-Typ “Debug” und für alle gewünschten Projekte (außer Webprojekte) einen anderen Typ z.B. “Debug_CodeAnalysis” zu verwenden:

 image

7. Teambuild mit Codeanalysis, CodeCoverage und UnitTests:

Jetzt sind wir schon ziemlich weit gekommen und freuen uns das endlich unser Webservice um den es im Projekt zentral geht auch über UnitTests auf dem Team Build Server jeder Zeit (z.B. jede Nacht – Continuous Integration) getestet werden kann. Verwendet man nun alle Features die zum Team Build dazu gehören, wie Code Analysis und Code Coverage, wundert man sich doch recht schnell warum die Coverage Werte sehr niedrig sind. Ein kleine Recherche in den erzeugten Dateien und Reports ergibt, dass alle UnitTests die über den WebService gelaufen sind nicht im CodeCoverage auftauchen ;(… Das ist natürlich schlecht!!! Wenn ich aber die WebService-Methoden nicht über die WebReference sondern direkt teste fehlt mir wieder der HTTP-Context in den Tests.) Was ist hier nun die beste Lösung? Mocking vom HTTPContext und wieder ohne WebReference testen?

image

WordPress Tags: Team,Build,Webservice,UnitTests,PathToWebRoot,Test

Advertisements

2 Kommentare

  1. Meiner Meinung nach sollte man keine Webservices und Datenbankaufrufe etc. direkt mit in die Unittests integrieren.
    Keine Frage: Getestet müssen diese auch, aber je mehr Webservices und co. man in die Tests einbindet, desto langsamer wird die Geschichte und die Tests haben plötzlich viele Abhängigkeiten. Wenn die Tests zu lange laufen, werden die Entwickler wahrscheinlich auch kaum alle Tests immer wieder abspielen.
    http://haacked.com/archive/0001/01/01/unit-test-boundaries.aspx

    Ich würde immer versuchen die einzelnen Komponenten für sich zu testen und die entsprechenden Abhängigkeiten zu mocken.
    Dann kann man noch ein gesonderten Integrationtest machen, sodass man auch mal sieht, ob beide Komponenten (verbunden über einen Webservice) auch das tun, was sie sollen 🙂


  2. Also vom Prinzip bin ich da ganz deiner Meinung. Trotzdem ist hier beschrieben, wie man es tun kann und wie es sowohl auf dem Team Build Server als auch auf dem Client möglich ist seinen WebService aus der Solution zu testen. Trotzdem finde ich es unschön, dass diese Tests nicht mit zur Code Coverage dazuzählen?
    Es gibt trotzdem auch Gründe Teile seines WebServices zu testen, denn die speziellen SOAPExceptions die von einem Client verarbeitet werden sollen, könnte man schon auch mal mit einem UnitTest provozieren. Das funktioniert leider nicht immer wenn man nur die ServiceImplementierung testet. Am Ende brauche ich im gezeigten Fall, aber nur einen Mock für den HTTPContext und schon sollte es funktionieren. Gibt es da eine schnelle und einfache Lösung?



Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: