Notes from Silverlight unit testing with the ESRI Silverlight API

I have been using the ‘Silverlight Unit Test Framework’ to do unit testing for our Silverlight applications. Unit testing applications using the ESRI Silverlight API throws a monkey wrench into the Silverlight unit testing process. The Silverlight unit testing libraries can normally be run with the automatically generate HTML page option in VisualStudio 2008. But unit tests with the ESRI Silverlight API map control will not run on the auto-generated HTML pages since the map control cannot load its layers when run from a web page on disk. So, to test the mapping applications, the unit tests should be run with a web application project which hosts the page over HTTP.

Well, that wasn’t a very painful solution was it? But the pain enters the picture when we have to run these Silverlight mapping unit tests on the build server. We don’t necessarily want to publish a web application just to run the Silverlight mapping unit tests. Ideally, we would just like to run the unit tests in the XAP file by themselves without publishing a web application with IIS on the build machine. In fact, our build machine does not run IIS. the ‘Silverlight Unit Test Framework’ doesn’t include any built-in support for such use cases.

But we can solve the problem above using the Statlight Silverlight testing automation tool. Statlight also provides support for integration with TeamCity, our build server of choice. The Statlight tool runs the test library XAP file over HTTP using a web server that it hosts when running. The tool is pretty simple to use and more details can be found at the ‘Getting Started’ page. I did run into some issues with running my tests over Statlight because of the fact that the Statlight tool actually creates it own XAP file when running the tests and copies over only the DLLs from the XAP file being tested. I had made use of some ‘Content’ files in my unit tests that didn’t get copied over and caused the issue. But I was able to solve the problem easily by switching the ‘Content’ files into embedded file in the DLL. Statlight’s creator was also kind enough to give me more information about the inner workings of the Statlight tool. Here it goes

 

1. Creates a webserver in the background. (hosted in the console)
2. Creates a browser in the background. (WinForm thread with a WebBrowser control)
3. The browser loads up StatLight silverlight application. (http://localhost:<port discovered>/…)
4. The silverlight application connects to the webserver and retrieves the xap to test via REST.
5. The SL app loads and exectues the tests in the xap.
6. The SL app reports results back to the webserver via WCF.
7. The webserver reports results back to the Console / CI server.

So, with Statlight, we can avoid unnecessary complexities with running Silverlight unit tests on the build server and report Silverlight mapping unit test results with the rest of the test results. If you are looking for solutions to running your Silverlight unit tests on your build server, i recommend looking into Statlight.

Advertisement