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: ) 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:

public MainPage()
    // set up unit testing
    UIElement testContainer = UnitTestSystem.CreateTestPage();
    ScrollViewer.Content = testContainer;
    MobileTestPage testPage = testContainer as MobileTestPage;
    if (testPage != null)
        testPage.UnitTestHarness.TestRunStarting += new EventHandler<Microsoft.Silverlight.Testing.Harness.TestRunStartingEventArgs>(UnitTestHarness_TestRunStarting);
        testPage.UnitTestHarness.TestMethodCompleted += new EventHandler<Microsoft.Silverlight.Testing.Harness.TestMethodCompletedEventArgs>(UnitTestHarness_TestMethodCompleted);
        testPage.UnitTestHarness.TestHarnessCompleted += new EventHandler<Microsoft.Silverlight.Testing.Harness.TestHarnessCompletedEventArgs>(UnitTestHarness_TestHarnessCompleted);


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:

private void UnitTestHarness_TestRunStarting(object sender, TestRunStartingEventArgs e)
    if (this.testRunInfo == null)
        this.testRunInfo = new TestRunInfo();
        this.testRunInfo.TestMethodInfos = new ObservableCollection<TestMethodInfo>();
private void UnitTestHarness_TestMethodCompleted(object sender, TestMethodCompletedEventArgs e)
    TestMethodInfo methodInfo = new TestMethodInfo();
    methodInfo.TestName = e.Result.TestMethod.Name;
    methodInfo.IsSuccess = e.Result.Result == TestOutcome.Passed;
    if (!methodInfo.IsSuccess && e.Result.Exception != null)
        methodInfo.FailInfo = e.Result.Exception.Message;
    methodInfo.TestClassName = e.Result.TestClass.Name;
private void UnitTestHarness_TestHarnessCompleted(object sender, TestHarnessCompletedEventArgs e)
    this.testRunInfo.TestRunEndedTime = DateTime.UtcNow;
    this.testRunInfo.IsSuccess = !e.State.Failed;
    this.testRunInfo.NumberOfTests = e.State.TotalScenarios;
    this.testRunInfo.NumberOfFailures = e.State.Failures;
    this.testComServ.WriteTestResultsCompleted += this.OnWriteTestResultsCall_Completed;
    this.testComServ.WriteTestResultsAsync(this.testRunInfo, "TestResults");

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.

Deyan Ginev
About the Author

Deyan Ginev

Deyan has been with Telerik for more than ​six years working on several different products with main focus on mobile technologies. Deyan is currently working on NativeScript– a platform for developing native mobile apps with JavaScript. Find him on Twitter via

Related Posts


Comments are disabled in preview mode.