Running Silverlight unit tests in TeamCity using StatLight
JetBrains TeamCity is a wonderful product that we use for build management and continuous integration in our .NET and Java projects. The latest version adds support for .NET 4 among other things. However, it does not come with support for running Silverlight unit tests out of the box. In this post I will describe what I did to set this up in TeamCity 5.1.
Building the Silverlight project
First of all I am assuming that you have setup a configuration in TeamCity that is able to build your Silverlight project successfully on the server.
I had some problems with building our Silverlight project at first because we are using WCF RIA Services and there does not seem to be any way to install the SDK without having VS2010 installed. Well, actually there is one way but it doesn’t install the Silverlight client libraries that you need to build but only the things you need to run RIA projects on the server. I finally gave in and installed VS2010 on the server although I didn’t like it. However, that solved the build issues for me.
Setting up StatLight configuration
Next we take advantage of a lovely little tool called StatLight. It is used to run Silverlight tests more efficiently when you are practicing TDD. It runs the tests without showing the browser window that the regular SLUT framework uses and it has a really nice “continuous” mode that can monitor your project and re-run tests automatically whenever you rebuild your solution. Last but not least, it has support for producing TeamCity compatible reports of the test run!
To use StatLight with TeamCity we need to create a new build configuration to run a command line build. I set it up like this:
You can set the general settings as you like but I used the defaults for most of it.
Version Control Settings
Under the VCS settings I made sure to set the same checkout directory as I have in my main build configuration. The idea here is to reuse the output from that project when we run this one.
Next is the Build Runner settings. Here I have specified that I want to run a command line tool and the path to it is:
This will run StatLight from within the checked out sources where I have put my tools used for building.
If you want you can of course put StatLight in some other path on your server, but I like to include the tools needed to build in the version control system so the right versions of the tools for a project are always present. This way I can upgrade tools in one project and simply commit them in version control and have the build server pick it up automatically.
Next I also needed to configure the parameters to give StatLight:
-x="Source\Tests.Gws3.Client\bin\Release\Tests.Gws3.Client.xap" -v=April2010 –teamcity
This tells StatLight where to find the XAP-file with the tests. (This file was actually built using our main build configuration so we need to setup a dependency on that.) We also specify which version of the testing toolkit we want to use and that we want StatLight to output a TeamCity compatible report.
Next up is Build Triggering settings. When do we want to run our tests? Well, I think it is a good time to run them whenever our main build has been built successfully so I setup a build dependency trigger for that.
So are we done yet? No, not quite…We also need to specify that our build configuration is dependent on stuff from another build project. This means that if that project is out of date it will be rebuilt before we run ours.
It seemed like a lot of steps to get it all up and running but it really isn’t that much work and once it is setup you can enjoy full continuous integration bliss for your Silverlight projects as well!
If you haven’t tried out TeamCity yet I suggest you check it out! It is free for up to 20 build configurations which should be more than enough to get you started.