"Fast" Integration Testing of WCF Services

Question

Context

I am a huge fan of what Roy Osherove calls "Fast Integration Testing." This is integration testing that:

• Is performed strictly on your development box. No need for a separate environment.
• Despite being integration testing, such tests are usually launched from your unit testing tool (NUnit, MsTest, etc.)
• Usually runs in-memory: a single process executes.
• Runs fast. There should not be seconds-long deployment followed by seconds-long boot-strapping, etc.
• Must be source control friendly:
  • Other developers should be able simply to pull the source and run the fast integration tests, without having to battle configuration issues (e.g. setting up IIS virtual directories, etc.)
  • Whenever possible, it should be compatible with continuous integration (CI) automated tests.

Problem

Given a VS 2010 solution with several WCF services to be integration tested, I've been researching how best to go about this. My further requirements of the test setup are:

• The WCF services are nested. That is, one service might call another during the fast integration test.
• The WCF stack must be fully or mostly operational.
  • Calling the service contract entry point directly might be ok for unit testing, but not for this form of integration testing.
  • REST and BasicHttp bindings should work, and preferably wsHttpBinding as well.
• Web.config
  • The web.config transform (XDT) of each WCF project should be operational, even though a deployment may or may not occur to achieve this test.
  • The unit test tool, such as MsTest or NUnit, should not require a consolidated web.config that represents all the services that will be hosted during the test.
• The WCF service hosting can be 32 bit or 64 bit.
• The WCF service hosting could be either in-memory with the unit test tool, or out-of-process through such hosts as Cassini, IIS Express, etc.
  • I'm definitely leaning towards an in-memory approach, because it simplifies test-synchronization issues. In other words, some of my WCF services execute asynchronously and are completed after the WCF response has already been sent to the text fixture. With the in-memory approach I can make the test fixture Monitor.Wait to ensure async work is completed before the test exits. For multi-process hosting and testing, I likely must rely on the file system and file system events to achieve the same synchronization.

Answer?

I want to list my findings so far, and ask what tool(s) or technique(s) I'm missing. Again, this question pertains to Visual Studio 2010, though additional comments about 2012 are welcome.

For in-memory solutions, it seems there are two fundamental choices. Either use one instance of a custom ServiceHost for each service, or use one of a variety of other self-hosting tools. In that second link, the original question was about production hosting - but most of the listed tools are capable of self or in-memory hosting.

The author of CassiniDev, mentioned in the second link above, suggested CassiniDev is used when loopback-testing (localhost) is not sufficient. In my case, I suspect loopback-testing is fine. That author suggests that when loop-back testing is ok, then a more lightweight story is to use his WebDevServer code. If I understand correctly, the WebDevServer code is actually internal Visual Studio code that he reflected and modified for test-fixture self-hosting purposes.

For on-box (multi-process) solutions, I see there is a way to make Cassini fit the 64 bit requirement. Otherwise, for IIS Express or IIS, I'm not sure about developer-to-developer configurability issues. Normally when a developer configures IIS Express or IIS on a specific machine, usually other developers are left without that config info and are struggling to make the test work on their own box. I've seen developers produce scripts that use appcmd.exe to automate such configuration, but all too often such scripts are poorly maintained. I want to try to avoid that scenario.

In either scenario, I believe my option(s) for automating the web.config transform (XDT), without a deploy, is discussed here.

Ok, what are the better strategies and tactics? I'd like to know...

Answer 1

This doesn't answer the question of fast integration testing as the asker requested, but the link below is the most comprehensive guide on how to make WCF testable.

https://codereview.stackexchange.com/questions/33379/make-wcf-service-testable?newreg=016e2809b68248958ff3c45973efe643

However, I cannot vouch for how far this guide will take you in terms of developing tests for the full stack of WCF functionality.