It’s been a while since the last blog on this topic but it’s for good: we have been heavily working on our upcoming Beta 2 release. The amount of feedback we received from you was extremely valuable and we managed to address many issues and make our suite more polished than ever. Keep in touch since the official release is coming and we’re very excited to share with you what we wouldn’t practically achieve without your support.
Now back on the topic; essentially, this blog covers the last technical aspect of the whole WP7 Unit Test Automation Infrastructure with the last blog of the series being an overview of the whole concept. As already mentioned earlier, the communication point between the unit test application and the MSBuild task that executes it to read the test results is a web service. The reasons for this approach, in brief, are related to the fact that currently there is not a straightforward way to perform I/O operations with the IsolatedStorage of an application installed on the WP7 emulator. In this context, a web service is a reasonable solution since both the MSBuild task and the phone application can access it to read/write information.
The API of the web service consists of two methods which are used to store or read information about a single unit test execution procedure. The code snippet below represents their implementation:
fileName = TARGET_DIR + sourceKey +
XmlSerializer serializer =
(XmlWriter targetWriter = XmlWriter.Create(fileName))
TestRunInfo result =
(XmlReader reader = XmlReader.Create(fileName))
result = serializer.Deserialize(reader)
You may have already noticed the TestRunInfo type. To avoid any confusion it is worth noting that this type is a container for the information about the execution of all unit tests within the application launched by the MSBuild task. You can use any type of custom objects to serialize this information; it is up to a personal approach. I have chosen to create a model for the information. There is also a string argument which is simply a unique identification for each result set stored on the build machine (using the same keys would simply overwrite test results). Another important part is the location where test results are stored by the web service. In this particular implementation this is the build machine where the web service runs.
So basically, as the diagram above shows, the MSBuild task launches the unit test application and starts calling the ReadTestResults method of the web service. On the other hand, the unit test application stores information about each unit test execution and at the end calls the WriteTestResults method with the corresponding arguments. Once the results are ready, the MSBuild task reads them and integrates them into the final build log.
In the next and last blog post from this sequence I will summarize this approach of automated unit test execution. I will also discuss some challenges that we have been facing while using it and the approaches we used to solve them.