语境
我非常喜欢 Roy Osherove 所说的“快速集成测试”。这是集成测试：
- 严格在您的开发箱上执行。不需要单独的环境。
- 尽管是集成测试，但此类测试通常是从您的单元测试工具（NUnit、MsTest 等）启动的。
- 通常在内存中运行：单个进程执行。
- 跑得很快。不应该有几秒钟的部署，然后是几秒钟的引导等。
- 必须对源代码控制友好：
- 其他开发人员应该能够简单地提取源代码并运行快速集成测试，而无需解决配置问题（例如设置 IIS 虚拟目录等）
- 只要有可能，它应该与持续集成 (CI) 自动化测试兼容。
问题
给定一个 VS 2010 解决方案，其中包含几个要进行集成测试的 WCF 服务，我一直在研究如何最好地解决这个问题。我对测试设置的进一步要求是：
- WCF 服务是嵌套的。也就是说，一个服务可能会在快速集成测试期间调用另一个服务。
- WCF 堆栈必须完全或大部分可操作。
- 对于单元测试，直接调用服务契约入口点可能是可以的，但对于这种形式的集成测试则不行。
- REST 和 BasicHttp 绑定应该可以工作，最好是 wsHttpBinding。
- 网页配置
- 每个 WCF 项目的 web.config 转换 (XDT) 应该是可操作的，即使可能会或可能不会发生部署来实现此测试。
- 单元测试工具（例如 MsTest 或 NUnit）不应该需要一个整合的 web.config 来表示测试期间将托管的所有服务。
- WCF 服务托管可以是 32 位或 64 位。
- WCF 服务托管可以使用单元测试工具在内存中进行，也可以通过 Cassini、IIS Express 等主机在进程外进行。
- 我肯定倾向于内存中的方法，因为它简化了测试同步问题。换句话说，我的一些 WCF 服务是异步执行的，并且在WCF 响应已经发送到文本夹具之后完成。使用内存中的方法，我可以制作测试夹具
Monitor.Wait以确保在测试退出之前完成异步工作。对于多进程托管和测试，我可能必须依靠文件系统和文件系统事件来实现相同的同步。
- 我肯定倾向于内存中的方法，因为它简化了测试同步问题。换句话说，我的一些 WCF 服务是异步执行的，并且在WCF 响应已经发送到文本夹具之后完成。使用内存中的方法，我可以制作测试夹具
回答？
我想列出我迄今为止的发现，并询问我缺少哪些工具或技术。同样，这个问题与 Visual Studio 2010 相关，但欢迎对 2012 发表更多评论。
对于内存解决方案，似乎有两种基本选择。为每项服务使用一个自定义 ServiceHost实例，或使用多种其他自托管工具之一。在第二个链接中，最初的问题是关于生产托管 - 但大多数列出的工具都能够自我或内存托管。
上面第二个链接中提到的CassiniDev的作者建议在环回测试（localhost）不足时使用 CassiniDev。就我而言，我怀疑环回测试很好。那位作者建议，当环回测试没问题时，一个更轻量级的故事是使用他的WebDevServer 代码。如果我理解正确，WebDevServer 代码实际上是内部 Visual Studio 代码，他反映和修改了用于测试夹具自托管目的。
对于机上（多进程）解决方案，我看到有一种方法可以让Cassini 满足 64 位要求。否则，对于 IIS Express 或 IIS，我不确定开发人员对开发人员的可配置性问题。通常，当开发人员在特定机器上配置 IIS Express 或 IIS 时，通常其他开发人员没有该配置信息并且正在努力使测试在他们自己的机器上工作。我见过开发人员制作使用 appcmd.exe 来自动执行此类配置的脚本，但此类脚本通常维护不善。我想尽量避免这种情况。
在这两种情况下，我相信我在此处讨论了无需部署即可自动执行 web.config 转换 (XDT) 的选项。
好的，更好的策略和战术是什么？我想知道...