Im Webcast UI Automation Framework haben wir prinzipiel aufgezeigt, wie man ein UITest für eine Winforms Anwendung mit Hilfe des UI Automation Frameworks erstellen kann und wie diese in einen UnitTest integriert werden können.
Im folgendem möchte ich aufzeigen wie man einen solchen UI-UnitTest in Team Build integrieren kann.
Was ist zu tun?
UITest benötigen eine "Interactive Session", wir müssen also einen Interactive Build Agent definieren und den Build Service entsprechend für einen Interactive Port konfigurieren. Die notwendigen Schritte sind unter folgendem Link beschrieben.
Danach kann man den Build Agent konfigurieren (mit dem Interactive Port):
Bevor man Builds mit diesem Agent ausführen kann, muss der Interactive Build Service auf dem
BuildServer gestartet werden. Für UI-Tests ist es erforderlich, dass ein Account angemeldet ist
und in diesem Kontext der Interactive BuildService gestartet wurde. Ich habe dies mit einem
Batch automatisiert:
StartInteractiveBuildService.bat
runas /user:TFSBUILD /savecred "cmd /k \"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSbuildservice.exe\""
Nun kann eine Build Definition erstellt werden, welche den BuildAgent verwendet.
Eine Hürde gilt es aber noch zu nehmen, für die es aber je nach Anforderung unterschiedliche Lösungsansätze gibt.
Der Unit-Test muss das UI automatisch starten/schliessen. Im Prinzip sehr einfach, allerdings liegt das im Build erzeugte UI-image in Abhängigkeit von verschiedenen Parametern in unterschiedlichen Pfaden. Die Abhängigkeiten sind z.B. Desktop Build oder Team Build, Debug Build oder Release Build,. In allen Fällen ergibt sich ein anderer Pfad zum Image.
Beispiel:
Desktop Build: "BasePath\Calc\bin\Debug\calc.exe"
Team Build: "BasePath\Binaries\Debug\calc.exe"
wobei der BasePath auch unterschiedlich ist, aber im Test Kontext verfügbar ist.
Ich habe mir für dieses Beispiel ein Anforderungsrahmen gegeben:
- keine Änderung der Default Build-Pfade
- der UnitTest soll das Image immer Starten/Beenden, ob DesktopBuild oder TeamBuild
- es wird Debug- und Release Build-Konfiguration unterstützt
Nun zu den Details.
Die Demo Solution enthält 3 Projekte:
- Calc (das UI-Image, welches getestet werden soll)
- UIDriverLib (Wrapper für das UI-Automation Framework, ich empfehle den White Wrapper zu verwenden)
- UIDruverLibTests(enthält die Unit-tests)
Der Fokus liegt auf der TestClass im UIDruverLibTests, welche 2 UnitTests enthält. Test1 ist ein nativer UI Test, der keinen Wrapper verwendet. Test2 verwendet den Wrapper. Details hierzu finden Sie im Webcast.
Um die oben beschriebene Hürde zu nehmen, habe ich die Logik zum Starten in die Region InitHelper gepackt. Das Beenden des Images muss im [TestCleanup()] durchgeführt werden, um sicherzustellen, dass keine UI's auf dem BuildServer verbleiben.
Die InitHelper Region enthält mehrere Helper Methods. Im Unit-Test verwende ich nur InitUIImage(). um das Image zu starten, die anderen Methoden sind Helper für InitUIImage().
Da ich im UnitTest einige Parameter benötige, um den Pfad für das UIImage zu erstellen, habe ich mich entschieden die wichtigsten Parameter nicht direkt im Test als Konstanten zu definieren, sondern diese als zusätzliche Test-Properties abzulegen und somit im UI zugänglich zu machen:
Mit GetCustomProperties lese ich diese Properties dann aus. GetImagePath enthält dann die Logik den Pfad in Abhängigkeit aller Parameter zu erstellen. StartUIImage startet dann das Image.
Auf diese Weise kann ich den UI Unit-Test auf dem Desktop oder als TeamBuild, als Release oder Debug ausführen.
Das Beispiel ist reiner Demo code, was man auch an den Sleep's sieht (sonst gehts einfach zu schell). Dennoch hoffe ich, die ein oder andere Idee gegeben zu haben, UI-Automation als Teil des Build Prozesses zu implementieren. In Prodcution das entsprechende Exception Handling nicht vergessen!
Ausblick: Coded UI-tests sind schon jetzt im aktuellen Rosario CTP 12 enhalten :-)
Mit der Option den code aus einem Recording erstellen zu lassen:
Viel Spass
Chris