Last week I started a blog post series that introduces our approach of automating the Windows Phone unit test execution on our build machines simply sharing the idea behind the automation infrastructure. I have also prepared a diagram that follows the automation process and have structured what I plan to share with you in the following weeks. Now, with the second post of the series I am going to make a more detailed technical overview of our infrastructure and give some reasons for choosing the discussed approach.
The Dedicated Build Task and communication with the Windows Phone 7 emulator
As already mentioned, we have a dedicated MSBuild task that launches the test application on the Windows Phone emulator and reads the test results. To accomplish this scenario I am using the Microsoft.SmartDevice.Connectivity API (found in \Program Files (x86)\Common Files\microsoft shared\Phone Tools\CoreCon\10.0\Bin; documentation available at: http://msdn.microsoft.com/en-us/library/microsoft.smartdevice.connectivity(VS.90).aspx). This API exposes a bunch of methods that allow for automating the Windows Phone 7 emulator. For instance, the build task uses it to deploy and run the freshly built unit test application on the emulator. This API also provides methods for exchanging data with an installed application but unfortunately calls to these methods are not allowed in the latest version of the WP7 tools. Therefore, we had to think of another approach of reading the test results from our test application. Here we decided to utilize a web service which would simply expose two methods that can be used to store and read results on and from the build machine’s hard drive. The read method is to be used by the dedicated build task and the write method is to be used by the test application to store test results when finished.
So at the end of the day, when the dedicated build task starts the test application on the emulator it also starts polling for results by calling the web service. When the test application finishes, it writes a XML file in a predefined directory on the build machine that is also known by the dedicated build task. Once written, the file is discovered by the build task and integrated into the final MSBuild log for the project.
The Dedicated Build Machine
The projects that integrate unit test execution are explicitly configured to run on a build machine that must not be a virtual machine. This is implied since the Windows Phone 7 emulator, where the unit tests are actually run, cannot be started on a virtual machine (being itself one). The dedicated build machine also hosts the web service through which the build task and the unit test application exchange test result information. The picture below describes the topology of the whole unit test automation infrastructure:
In the next blog of the series I am going to talk about the implementation of the dedicated build task by showing some actual code so stay tuned to see how you can use this approach in your projects.