Nicht immer steht in TFS-Umgebungen ein komplettes Lab Management zur Verwaltung der virtuellen und physischen Testumgebungen zur Verfügung. Aber auch ohne die Lab Management Features können automatisierte Oberflächentests während des Build-Prozesses ausgeführt werden. Im folgenden sollen Optionen für die Einrichtung der Umgebung für diesen Zweck vorgestellt werden.
Option 1: Lokal
CodedUI-Tests liegen in Form von ausführbaren Code-Fragmenten vor, die über die MSTest-Engine so wie Unit-Tests auch ausgeführt werden. CodedUI-Tests werden im Visual Studio erstellt und in Testprojekten einer Solution gepflegt. Wie auch andere Testtypen z.B. Unit-Tests können diese lokal ausgeführt vom Entwickler werden. Da sie praktisch an der (Windows-) Oberfläche arbeiten, müssen die Tests in einem sogenannten Interactive Process ausgeführt werden – sie können z.B. nicht in einem Windows-Service-Kontext laufen. Allerdings läuft der gesamte Buildprozess auf einem Build-Agent des TFS in einem solchen Windows-Dienst – dem Build Service Host.
Option 2: Über Build Service lokal auf dem Build Agent
Der Build Service Host kann aber umgestellt werden, sodass dieser als interaktiver User-Prozess ausgeführt wird. Dies lässt sich in der Team Foundation Server Administration Console über die Eigenschaften des Build Service auf der Agent-Maschine einstellen (Beachten Sie, dass der Build-Service dafür zunächst angehalten werden muss):
Abbildung 1: Team Foundation Server Administration Console (Build Agent)
Abbildung 2: Einstellungen des Build Service Hosts
Im Anschluss loggen Sie sich auf dem Agent als “tfsbuild” bzw. mit Ihrem Build-Service-Account ein und starten den Service. So können CodedUI Tests lokal in einem Prozess gestartet werden, der mit der Oberfläche interagiert. Um die Tests auszuführen, müssen diese in den Build eingebunden werden. Das wird in den Einstellungen der Build-Definition erreicht:
Abbildung 3: Auswahl der Test Assembly
Der interaktive Prozess ist für den Build-Prozess allerdings nicht die eleganteste Lösung, ist dieser doch sehr anfällig für Fehler. Da ist ein Windows-Dienst mit seinen Recovery-Einstellungen besser stabiler.
Option 3: Remote via Test-Controller vom Entwicklerrechner
Eine Alternative bietet die Remote-Testausführung über einen Test-Controller. Dazu wird wie vermutet ein Test-Controller sowie ein ausführender Test-Agent benötigt. Ein ähnliches Konstrukt wie beim Build-System des TFS. Die Komponenten befinden sich allerdings nicht auf dem TFS-Installationsmedium, sondern auf einem separaten ISO “Visual Studio 2010 Agents”. Installieren Sie z.B. Test-Controller und –Agent auf ein und derselben Maschine und stellen sie diese wie folgt ein.
Tipp: Benutzen Sie dazu den jeweiligen Configuration Wizard, der nach der Installation über das Start-Menü verfügbar ist.
Abbildung 4: Den Controller nicht an der Collection registrieren!
Der Controller darf nicht an der Team-Project-Collection registriert werden, da dieser sonst nicht für das reguläre Remote-Testen über Visual Studio zur Verfügung steht – er wäre im Lab Management eingebunden. Der Test-Agent wird wiederum als Ersatz zum Build-Agent als interaktiver Prozess gestartet.
Abbildung 5: Einstellungen des Test-Agents
Nach der Einstellung läuft der Test-Agent sichtbar auf dem Desktop der Maschine:
Abbildung 6: Die Oberfläche des Test-Agents
Um den Test-Agent während der Testausführung aus dem Visual Studio heraus zu instrumentieren, müssen die Testeinstellungen – also die .testsettings Datei – verändert werden. Gehen Sie dazu bei geöffneter Visual Studio Solution in das Test-Menü unter Edit Test Settings. Stellen Sie sicher, dass Sie eine neue .testsettings Datei anlegen, um jederzeit auf die lokalen Einstellungen zurückspringen zu können. In den Einstellungen müssen Sie lediglich die Ausführungsmethode auf Remote umstellen und einen Test-Controller angeben:
Abbildung 7: Remote-Testeinstellungen
Setzen Sie die erstellte Testeinstellungsdatei zudem als aktive Testeinstellung ein:
Abbildung 8: Aktive Testeinstellung auswählen
Sobald Sie nun Tests und insbesondere CodedUI-Tests ausführen, werden diese auf dem Test-Controller ausgeführt. Beachten Sie den Test-Agent in der nächsten Abbildung.
Abbildung 9: Test-Agent während der Testausführung
Über die Diagnostic Data Adapters werden zudem Daten während der Testausführung erhoben. Das können Systeminformationen wie in nachfolgender Abbildung dargestellt, aber auch Video-Aufnahmen und IntelliTrace-Logs sein.
Abbildung 10: Test Result Details des CodedUI-Tests
Option 4: Remote während des Build-Prozesses
Fehlt nur noch die Integration in den Build-Prozess. Damit der Build-Prozess die Tests ebenfalls im Kontext des Test-Controllers startet, müssen die Testeinstellungen via Remote.testsettings Datei im Build-Prozess integriert werden:
Abbildung 11: Build-Definitionseinstellungen für die Instrumentierung des Test-Controllers
Im Anschluss sind die Testergebnisse im Build-Report verfügbar:
Abbildung 12: Buildergebnisse mit Testlauf
Diese können wiederum durch klicken auf “View Test Results” direkt im Visual Studio geöffnet und analysiert werden.
Fazit
Auch ohne die Verwendung von Lab Management bieten die Test-Controller mit der Ausführung von Tests auf dedizierten Maschinen die Möglichkeit, nicht nur CodedUI-Tests in den Build zu integrieren, sondern gleichsam für die Standardisierung der Testumgebung zu verwenden.
1 Kommentar