Welcome to MSDN Blogs Sign in | Join | Help

Unit Testing WCF Services

A few years ago, when ASP.NET web services were the only (or at least most common) implementation of web services on the Microsoft platform, you couldn't really unit test services. Obviously, since you had programmatic access (via a proxy class) to the service, you could write tests against the service using unit testing tools, but in my terminology, these tests are integration tests, not unit tests.

This lead to the guiding principle that a service should just be a remote façade for a service library; that service library could then be subjected to unit testing, and the service itself would just delegate all messages to the library (and thus contain so little code that it didn't require testing in itself).

With WCF, this is no longer the case, since WCF services are just libraries. This means that you can just add a reference to your service from a test project, and start writing tests against the library like this:

[TestMethod]
public void DoStuffInProcess()
{
    MyService ms = new MyService();
    string result = ms.DoStuff("Ploeh");
    Assert.AreEqual<string>("Ploeh", result);
}

However, to be able to do this, you must ensure that the service library doesn't use any WCF-specific code. As soon as you begin to use OperationContext.Current in your service, your unit tests are very likely to fail, since this static property will be null when not hosted by WCF.

Although this may feel like too much of a constraint, this is often a beneficial approach, since it helps ensure separation of concerns. Service operations should implement business logic, not transport logic or other, similar kinds of unrelated activity.

While that may be true, you will often still need to know something about the context of the operation, such as the identity of the caller. In many cases, such requirements can still be addressed while maintaining separation of concerns, since WCF allows you to configure message interceptors, authorization managers, etc.

Even if you are able obtain perfect separation of concerns, you may still want to test your authorization managers or other extensions, and that will often require hosting by WCF. In such cases, integration testing is the proper approach, but that doesn't mean that you shouldn't unit test as far as you can get.

In future articles, I will write about integration testing of WCF services. Update: My first WCF integration testing post is now online.

Published Sunday, December 03, 2006 3:58 PM by ploeh
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Unit Testing WCF Services

Sunday, December 03, 2006 7:36 PM by Jimmy Rasmussens Blog

A colleague of mine recently wrote about seperation of concerns in relation to unit testing WCF services.

# re: Unit Testing WCF Services

Monday, December 04, 2006 11:35 AM by Sean.McLellan

Great post!

In my organization we've been trying to figure out a way to unit test our services and this is exactly the scenario that we've discussed.  However, we DO use OperationContext.Current in our services in order to get identity info, and so we're currently developing our unit tests around the client proxy.

I'll be looking forward to your future posts about how to do the integration testing -- I hope there's a way to latch into the WCF pipeline and have OperationContext.Current provide identity information without having to have the service be executing under WCF.

# Integration Testing WCF Services

Monday, December 04, 2006 2:42 PM by ploeh blog

In my previous post about unit testing WCF services , I hinted at the need to perform integration testing

# re: Unit Testing WCF Services

Monday, December 04, 2006 2:54 PM by ploeh

Hi Sean

Glad you liked the post :)

As you may have noticed, I've just posted my next article about WCF integration testing, although this particular article doesn't address the separation of concerns between service operations and, say, authorization.

I may get to this subject in a later post, but until then, take a look at ServiceAuthorizationManager. Deriving from this class basically lets you write your authorization logic in a central place so you don't need to access OperationContext.Current in a lot of other places. In a custom authorization manager, you can, after authorizing the caller, extract all the necessary information about the caller and create an IPrincipal instance and place it on Thread.CurrentPrincipal.

# Mapping SAML Tokens to IPrincipals

Thursday, January 04, 2007 1:49 PM by ploeh blog

In my post about integration testing of WCF services , I briefly touched on the topic of authorization

# re: Unit Testing WCF Services

Tuesday, December 11, 2007 9:51 AM by Brad.Gearon

I also feel this post is well written and very nicely explained.  Looking at it like that makes me wonder why I had questioned the method in the first place.

# re: Unit Testing WCF Services

Tuesday, December 11, 2007 10:28 AM by ploeh

Hi Brad

Thanks - glad you liked it :)

# Implementing WCF Services Without Referencing WCF

Thursday, June 26, 2008 3:24 AM by ploeh blog

More than a year ago, I wrote my first post on unit testing WCF services . One of my points back then

# Unit Testing ADO.NET Data Services

Tuesday, January 13, 2009 7:05 AM by ploeh blog

ADO.NET Data Services enables you to expose data (including, but not limited to, relational data) as

# re: Unit Testing WCF Services

Wednesday, April 08, 2009 2:57 AM by Alex

A tool like WCFStorm might be useful in this case. It can create test cases  and invoke WCF methods so in a way you are doing Unit and Integration testing at the same time.

http://geekswithblogs.net/Erik/archive/2009/04/02/130664.aspx

# re: Unit Testing WCF Services

Thursday, April 09, 2009 4:38 AM by ploeh

Hi Alex

Thanks for sharing :)

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker