This is actually a blog post to share my problems with setting up a simple load test for WCF service testing with Visual Studio Team System 2008 Test Edition.
It looks very simple and it is very simple, if you know the trick.
Just for information purposes I tried to setup a load test for a very simple WCF service. It was a service running in IIS and a unit test project calling it. The unit test I wrote worked just fine, so I thought I could use that for the load test.
I added a new Test item and ran the wizard. So far so good. The first thing that went wrong when I tried to run the load test was that the Load Test database was missing. So I had to create the Load Test Results Repository myself. How to do that is described here, but it actually is nothing more than to run a SQL script. If the repository is created, set the connection string in the ‘Administer Test Controller’ menu.
Ready for the second try, but it failed again with the following error:
“System.InvalidOperationException: Could not find default endpoint element that references contract….”
It was clear that the load test couldn’t find the WCF client configuration somehow. After quite some searching I finally found this document with the solution.
When you create a new load test, the “Run unit tests in application domain” setting is false by default, however it should be true in my situation.
![runsettings2[1]](http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/jpsmit.metablogapi/8204.runsettings21_5F00_thumb_5F00_4B7C3F90.png "runsettings2[1]")
Like with most issues, once you know what term to search for it appears to be described fairly well. This quote is from this blog, specifying what this setting is doing:
“When a unit test is run by itself, a separate application domain is created in the test process for each unit test assembly. There is some overhead associated with marshalling tests and test results across the application domain boundary, so when running unit tests in a load test, the application domain is not created by default. This provides some performance boost in terms of the number of tests per second that the test process can execute before running out of CPU. The only drawback is that if the unit test depends on an app.config file, this doesn’t work without creating the app domain. In this case, you can enable the creation of app domain for the unit tests: in the Load Test editor’s Run Setting’s properties set the property “Run unit tests in application domain” to True.”
So after I set the setting to true, everything went smoothly and I must say that load testing is then very easy and cool to do.