Solved: Unit/Integration Testing of a WCF Service

ChrisD — Thu, 16 Sep 2010 13:06:31 GMT

I've got a solution to running and debugging unit tests for WCF hosted services that utilize the CMServiceHost. Whether your generate your serivce proxy via WSDL (Add Service Reference) or Shared Contract (ClientFactory), the solution is similar. This email will detail how to invoke a WCF Service Host for testing in both scenarios.

Testing a service client generated via "Add Service Reference"
I'll illustrate the solution using the following sample unit test. Let's assume you've created a service proxy for the "TestService" service with Add Service Reference, and assigned it to the "TestSvc" namespace. You're test looks like this:

   1:      [TestMethod]

   2:          public void Test_InvokeTestService()

   3:              {

   4:                  var client = new TestSvc.TestServiceClient();

   5:                  var pingResp = client.Ping();

   6:                  TestContext.WriteLine("Ping Response: {0}", pingResp);

   7:              }

Let's assume this service is hosted by our ChannelDelivery.Host project and the above test lives int he ChannelDelivery.Test project.

   1. Start by getting latest of the _ReferencedAssemblies in the dev branch of TFS.
   2. In your Test Project, add a reference to the Platform.UnitTests_Utilities assembly (its available in the _ReferencedAssemblies\Framework folder in the Applications solutions).
   3. Decorate your unit test with the AspNetDevelopmentServer attribute. This attribute takes two arguments; a unique host idenfiter, and the location of the web site to run. Assuming You're running this for the ChannelDelivery unit tests, you'd specify the arguments as follows: [AspNetDevelopmentServer("ChannelDeliveryHost", @"ChannelDelivery\ChannelDelivery.Host")]
   4. In your unit test code, after your create your service proxy, and before you invoke the service operation, add a call to

client.Endpoint.Address= WebTestHelper.GetRedirectedEndpointAddress("ChannelDeliveryHost", TestContext, client.Endpoint.Address);

Your code should now resemble:

      [TestMethod]
    [AspNetDevelopmentServer("ChannelDeliveryHost", @ "ChannelDelivery\ChannelDelivery.Host")]
            public void Test_InvokeTestService()
            {
                var client = new TestSvc.TestServiceClient();
               client.Endpoint.Address= WebTestHelper.GetRedirectedEndpointAddress("ChannelDeliveryHost", TestContext, client.Endpoint.Address);
                var pingResp = client.Ping();
                TestContext.WriteLine("Ping Response: {0}", pingResp);
            }

Testing a service client that shares service contract and uses ClientFactory.
I'll illustrate the solution using the following sample unit test. Let's assume you've created a service proxy for the "EchoService" service using the ClientFactory. You're test looks like this:

            [TestMethod]
            public void Test_ChannelDeliveryEcho()
            {
                using (var svc = ClientFactory.ProduceServiceClient<IEchoService>())
                {
                    TestContext.WriteLine("Echo Test Results:" + svc.Client.Echo("Echo!"));

}
}

To enable integration testing of the EchoService:

   1. Start by getting latest of the _ReferencedAssemblies in the dev branch of TFS.
   2. Decorate your unit test with the AspNetDevelopmentServer attribute. This attribute takes two arguments; a unique host identifier, and the location of the web site to run. Assuming You're running this for the ChannelDelivery unit tests, you'd specify the arguments as follows: [AspNetDevelopmentServer("ChannelDeliveryHost", @"ChannelDelivery\ChannelDelivery.Host")]
   3. In your unit test code, after your create your service proxy, and before you invoke the service operation, call the RedirectServiceUri method on the service proxy, passing a reference to the TestContext.

Your code should now resemble:

            [TestMethod]
            [AspNetDevelopmentServer("ChannelDeliveryHost",@"ChannelDelivery\ChannelDelivery.Host")]
            public void Test_ChannelDeliveryEcho()
            {
                using (var svc = ClientFactory.ProduceServiceClient<IEchoService>())
                {
                    svc.RedirectServiceUri(TestContext);
                    TestContext.WriteLine("Echo Test Results:" + svc.Client.Echo("Echo!"));
                }
            }

Summary
When you debug or run this unit test, the AspNetDevelopmentServer (the one that runs when you press f5 on your web site), starts up and runs on a random port. The WebTestHelper and RedirectServiceURI methods, uses the currently executing test context to determine the random port assignment, and determines the new service address based on the random port and current service uri. The methods also ensure the new uri is valid by attempting to send a POST request to the uri.

You can now run your integration unit tests that rely on hosted wcf services.

The code for GetRedirectedEndpointAddress (aka GetRedirectedUriString) follows:

Code Snippet

 
public static string GetRedirectedUriString(object TestContext, string defaultUriStr)
{
    return GetRedirectedUriString(TestContext, defaultUriStr, null);
}
 
public static string GetRedirectedUriString(object TestContext, string DefaultUriStr, string HostIdentifier)
{
    Uri hostUri = getHostUriFromTestContext(TestContext, HostIdentifier);
    if (hostUri == null) return DefaultUriStr;
    var defaultUri = new Uri(DefaultUriStr);
    string newUriStr = hostUri.Scheme + "://" + hostUri.Authority + defaultUri.PathAndQuery;
    newUriStr = EnsureValidUri(new Uri(newUriStr));
    return newUriStr;
}
 
private static Uri getHostUriFromTestContext(object context, string identifier)
{
    const string DevServerKeyName = "AspNetDevelopmentServer.";
    const BindingFlags bindingFlags = BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance;
    PropertyInfo info = context.GetType().GetProperty("Properties", bindingFlags);
    if (info != null)
    {
        var contextProperties = info.GetValue(context, null) as Dictionary<string, object>;
        if (contextProperties != null)
        {
            if (string.IsNullOrEmpty(identifier))
            {
                var entry = contextProperties.FirstOrDefault(kvp => kvp.Key.StartsWith(DevServerKeyName));
                return entry.Value as Uri;
            }
            var uri = contextProperties[DevServerKeyName + identifier] as Uri;
            return uri;
        }
    }
    return null;
}
 
private static string EnsureValidUri(Uri targetUri )
{
    var uri = targetUri.ToString();
    for (int i = 0; i < targetUri.Segments.Length; i++ )
    {
        var response = WebTools.DoHttpPost(uri, null);
        if (response.Contains("404"))
        {
            while (targetUri.Segments[i] == "/")
                i++;
            if (i <= targetUri.Segments.Length)
                uri = uri.Replace(targetUri.Segments[i] , "");
        }
        else
            return uri;
    }
    return targetUri.ToString();
 
}
public static void WriteMessageToTestContext(object TestContext, string message)
{
    var mi = TestContext.GetType().GetMethod("WriteLine");
    if (mi != null)
    {
        var parameters = new object[] {message, new object[] {}};
        mi.Invoke(TestContext, parameters);
    }
}

Supporting Request Timeout with a WebClient

ChrisD — Tue, 14 Sep 2010 17:52:36 GMT

I recently needed to adjust the timeout value of the HTTP Request being generated by WebClient. My attempt to perform a POST of a large file over HTTP was causing the WebClient to timeout. I thought adjusting the timeout value for the web client would fix this problem. One problem, the WebClient doesn’t support a Timeout value.

I did some snooping via Reflector and discovered 2 important facts about the WebClient. Fact #1, The WebClient isn’t sealed. This means we can inherit from it. Fact #2: The WebClient factories the HTTP Request from a protected method called GetWebRequest. This means I’d only need to override the GetWebRequest method to affect the HTTP Request used by the web client.

so..

I created the following class:

Code Snippet
 public class ExtendedWebClient : WebClient
  {
      public int Timeout { get; set; }
 
      protected override WebRequest GetWebRequest(Uri address)
      {
          WebRequest request = base.GetWebRequest(address);
          if (request != null)
              request.Timeout = Timeout;
          return request;
      }
 
      public ExtendedWebClient()
      {
          Timeout = 100000; // the standard HTTP Request Timeout default
      }
  }
 

When I need to control the timeout of a request, I create an instance of my ExtendedWebClient and set the timeout property:

Code Snippet
  
using (var client = new ExtendedWebClient())
{
    client.Timeout = -1;
 

Let me know if you find this as useful as I did.

Solving “XmlSchemaException: The global element '<elementName>' has already been declared.”

ChrisD — Wed, 14 Apr 2010 15:01:53 GMT

I recently encountered this error when I attempted to consume a new hosted WCF service. The service used the Request/Response model and had been properly decorated. The response and request objects were marked as DataContracts and had a specified namespace. My WCF service interface was marked as a ServiceContract and shared the namespace attribute value. Everything should have been fine, right?

[ServiceContract(Namespace = "http://schemas.myclient.com/09/12")]
   public interface IProductActivationService
   {
       [OperationContract]
       ActivateSoftwareResponse ActivateSoftware(ActivateSoftwareRequest request);
   }

well, not exactly. Apparently the WSDL generator was having an issue:

System.Xml.Schema.XmlSchemaException: The global element 'http://schemas.myclient.com/09/12:ActivateSoftwareResponse' has already been declared.

After digging I’ve found the problem; the WSDL generator has some reserved suffixes for its entities, including Response, Request, Solicit (see http://msdn.microsoft.com/en-us/library/ms731045.aspx). The error message is actually the result of a naming conflict. The WSDL generator uses the namespace of the service to build its reserved types. The service contract and data contract share a namespace, which coupled with the response/request name suffixes I was using in my class names, resulted in the SchemaException.

The Fix:

Two options:

Rename my data contract entities to use a non-reserved keyword suffix (i.e. change ActivateSoftwareResponse to ActivateSoftwareResp). or;
Change the namespace of the data contracts to differ from the service contract namespace.

I chose option 2 and changed all my data contracts to use a “http://schemas.myclient.com/09/12/data” namespace value. This avoided a name collision and I was able to produce my WSDL and consume my service.