Silverlight Testing

Most developers will say that “testing and documentation have their place but right now I need to churn out code.” While developer’s need to develop without anyone handicapping their efforts, testing in a large part goes hand in hand with development and is why its featured within the application lifecycle management framework so prominently.

As projects continue to grow in complexity, testing becomes mandatory instead of an optional component. Most testing is confined to either ASP.NET applications or traditional Windows form applications. However, testing should also be incorporated in all projects especially those that deal with multimedia (i.e. video, audio, high-res graphics, etc.). That said; let’s take a look at how to incorporate testing within a Silverlight project.

Testing Types

I created a demo Silverlight project and added a test project. Two of the most important tests are web performance and load tests, both of which I’ve included in the project.

Creating a web performance test is extremely easy and it’s basically just a recording of what actions are taken when visiting a site. Of course this can be customized (e.g. parameterized login’s using user information obtained from a database) but for this example we’ll keep it simple - open a browser and just load the application. I will mention that any recorded test can be converted to a coded UI test by using the “Generate Code” option on the context menu which will give you full control over the customization of said test. That conversion yields somethig to the effect of this:

After running the test, verification of whether it passed or failed can be seen and any appropriate actions taken.

Now that there’s a web performance test created, let’s simulate some load on the application. Creating a load test is again a simple process; follow a wizard through a few steps and a fully functional load test will be generated. Incorporating load patterns (either constant, step or goal based), one or more web performance tests and test/network mixture yields the following results:

There are a few other tests that I’ll comment on and they are the ordered, generic and unit tests. Ordered tests are just that, tests that are in a container that guarantees that the tests run in a specific order. An example of an ordered test is the following:

A generic test wraps an existing test, program, or third-party tool. After that program has been wrapped as a generic test, Team System testing tools treats it like any other test type: You can manage and run it and obtain results using the same windows and tools just like the other test types.

Taking this one step further, integrating these tests within Team Foundation Server (TFS) provides visibility of said tests to the QA staff as they may not be running Visual Studio but Microsoft Test Manager (MTM) instead. Associating a Changeset to the test case which is then part of the user story illustrates the tight coupling that TFS provides between developers and testers.


Lately I sound like a broken record (remember those?) but testing is essential in development. Creating Silverlight projects doesn’t offer an exemption to this theory of thinking as with all the intricacies that this type of application poses, it shows the necessity for it.