All of you that have been following my blog series about our automated approach for WP7 unit test execution may have noticed that the last couple of weeks I did not manage to publish since I mainly focused on the preparations around our upcoming Beta 1 release. Although a bit late, this blog comes together with a very solid and exciting version of RadControls for Windows Phone 7 that will bring to you a bunch of new controls and tools to play with so keep in touch to see what’s under the hood.
With this blog I am going to introduce the second major component in our Unit Test Automation infrastructure – the WP7 test application that, after installed on the emulator, outputs the test results in XML format so that they can be easily integrated with the MSBuild log. This application is nothing more than a standard Unit Test App that utilizes the Silverlight for WP7 Unit Test Framework (read more about it here: http://www.jeff.wilcox.name/2010/05/sl3-utf-bits/ ) but modified to store the information about each unit test execution in an object and use the already mentioned web service to store the information on the build machine that executes the unit tests.
The described mechanism works by hooking some events that are fired each time a unit test is executed and bring useful information with them which we use to see whether the test has failed or not. To hook these events I use the UnitTestHarness object available from the Silverlight for WP7 Unit Test Framework. The following set up happens in the constructor of the main page of the app:
// set up unit testing
UIElement testContainer = UnitTestSystem.CreateTestPage();
ScrollViewer.Content = testContainer;
MobileTestPage testPage = testContainer
The TestRunStarting event is fired at the beginning of the unit test execution. TestMethodCompleted fires when a single unit test is finished and TestHarnessCompleted fires when all unit tests in the project are finished. Additionally, I have implemented a simple model – TestRunInfo – which is used to store the information about the unit test execution. This model is filled throughout the TestMethodCompleted and TestHarnessCompleted event chain as follows:
sender, TestRunStartingEventArgs e)
sender, TestMethodCompletedEventArgs e)
TestMethodInfo methodInfo =
methodInfo.TestName = e.Result.TestMethod.Name;
methodInfo.IsSuccess = e.Result.Result == TestOutcome.Passed;
(!methodInfo.IsSuccess && e.Result.Exception !=
methodInfo.FailInfo = e.Result.Exception.Message;
methodInfo.TestClassName = e.Result.TestClass.Name;
sender, TestHarnessCompletedEventArgs e)
.testRunInfo.TestRunEndedTime = DateTime.UtcNow;
.testRunInfo.IsSuccess = !e.State.Failed;
.testRunInfo.NumberOfTests = e.State.TotalScenarios;
.testRunInfo.NumberOfFailures = e.State.Failures;
The implementation of the TestRunInfo (and the accompanying TestMethodInfo) infrastructure is not important since its purpose is not bound to the Unit Test Automation Infrastructure. The aim here is to simply store the unit test execution information for further usage and thus these classes can be implemented in any way you would like to.
After filling the TestRunInfo object with information I am passing it to the web service which stores this information in XML format on the Build Machine and thus making it available for the waiting MSBuild Test Runner Task. The web service in question will be discussed in the next blog post of this series so keep in touch.