How to unit test a WCF server/client?

Question

I have a WCF server that is a library assembly. (I am writing it so I can mock the level below it) It is called var a client helper class that is in a different assembly. As the data that is transferred is complex and the server has to send call-backs to the clients I wish to test the WCF code in isolation.

(I am only interested in the TCP channel or NamePipe channel)

I do not wish to mock WCF, as the risk I am trying to control is my usage of WCF.

It there a easy way to

• Load my WCF server into a different app domain
  (I could load the WCF server into the main app domain, but then I it harder to prove that the objects were serialized correctly rather than just pointer moved about.)
• Setup all the WCF config so the client class can call it (most likely named pipes or TCP)
• And use it in some nunit test
• I rather not have my unit tests depending on config file.

I expect (hope) that there are some util classes for setting up WCF unit test that I can just pass the type of my server class to and will give me back a client factory that connects to the server.

Am I going about this the wrong way, e.g there a better way of testing my communication layer and usage of WCF?

Answer 1

You can use SOA Cleaner for testing your WCF. Take a look at http://xyrow.com no installation is needed. It's not unit testing, but it can be very helpful (you can have it run on your build, as it supports command line too).

Answer 2

It is by far the easiest approach if you spin up the service in-proc, because then you don't need to write a lot of complex synchronization code to determine when the service is running and when it isn't.

Don't worry about pointers being passed around - they won't (unless you choose the new in-proc binding in WCF 4). It's the binding that determines how and if objects are serialized. Named pipes are excellent for this purpose.

I always spin up a new ServiceHost in each test case inside a using statement, which effectively guarantees that the host is running before calls are being made to it, and that it is properly closed after each test. This last part is important because it ensures test independence.

You may also want to look at a series of blog posts I wrote about a very similar subject.