&引用；“快速”；WCF服务的集成测试 上下文

我是Roy Osherove所谓的“快速集成测试”的超级粉丝。这是一种集成测试：

• 严格在开发盒上执行。不需要单独的环境
• 尽管是集成测试，但此类测试通常是从单元测试工具（NUnit、MsTest等）启动的
• 通常在内存中运行：执行单个进程
• 跑得很快。不应该有秒长的部署，然后是秒长的引导，等等
• 必须对源代码管理友好：
  • 其他开发人员应该能够简单地提取源代码并运行快速集成测试，而无需解决配置问题（例如设置IIS虚拟目录等）
  • 只要可能，它应该与持续集成（CI）自动化测试兼容

问题 鉴于VS2010解决方案中有几个WCF服务需要进行集成测试，我一直在研究如何最好地实现这一点。我对测试设置的进一步要求是：

• WCF服务是嵌套的。也就是说，在快速集成测试期间，一个服务可能会调用另一个服务
• WCF堆栈必须完全或大部分可操作。
  • 直接调用服务契约入口点对于单元测试来说是可以的，但是对于这种形式的集成测试来说不是
  • REST和BasicHttp绑定应该可以工作，最好是wsHttpBinding
• Web.config
  • 每个WCF项目的web.config转换（XDT）都应该是可操作的，即使为实现此测试可能会进行部署，也可能不会进行部署
  • 单元测试工具（如MsTest或NUnit）不应该需要表示测试期间将承载的所有服务的统一web.config
• WCF服务宿主可以是32位或64位
• WCF服务宿主可以使用单元测试工具在内存中，也可以通过Cassini、IIS Express等主机脱离进程。
  • 我肯定倾向于内存中的方法，因为它简化了测试同步问题。换句话说，我的一些WCF服务是异步执行的，并且在WCF响应已经发送到文本设备之后完成。使用内存中的方法，我可以使测试夹具

    监视。等待
    以确保在测试退出之前完成异步工作。对于多进程托管和测试，我可能必须依赖文件系统和文件系统事件来实现相同的同步

回答？ 我想列出到目前为止我的发现，并询问我缺少什么工具或技术。同样，这个问题与VisualStudio2010有关，不过欢迎对2012发表更多评论

对于内存解决方案，似乎有两个基本选择。为每个服务使用一个实例，或使用一个实例。在第二个链接中，最初的问题是关于产品托管的——但列出的大多数工具都能够自行或在内存中托管

上面第二个链接中提到的作者建议在环回测试（localhost）不足时使用CassiniDev。在我的情况下，我怀疑环回测试是好的。该作者建议，当环回测试正常时，使用他的方法是一个更轻量级的故事。如果我理解正确的话，WebDevServer代码实际上是内部VisualStudio代码，他为了测试夹具自托管的目的反射和修改了这些代码

对于on-box（多进程）解决方案，我认为有一种方法可以实现。否则，对于IIS Express或IIS，我不确定开发人员之间的可配置性问题。通常，当开发人员在特定计算机上配置IIS Express或IIS时，其他开发人员通常没有该配置信息，并且正在努力使测试在他们自己的机器上工作。我见过开发人员使用appcmd.exe生成脚本来自动化此类配置，但这些脚本的维护往往很差。我想尽量避免这种情况

在任何一种情况下，我都相信我的选择

---

好的，有什么更好的策略和战术？我想知道…

这并没有回答提问者要求的快速集成测试问题，但下面的链接是关于如何使WCF可测试的最全面的指南

---

然而，我无法保证本指南将在开发WCF功能的完整堆栈测试方面为您带来多大的帮助。

好问题！我也想知道答案。这有意思吗？这有什么用呢？为了客观起见，测试应该由非开发人员完成，如果必须由开发人员完成，则绝对不能在开发它的机器上进行，特别是当系统涉及

通信时。相比之下，这就是为什么我们有编译产品的
构建机器
。您描述的不是集成测试，而是开发testing@MickyDuncan，我认为您错过了集成测试的要点。自动集成测试的存在是为了在连续的基础上检测破坏性的更改，从而帮助开发团队尽早发现缺陷并快速修复它们。客观性不是这个练习的主要目的——它是对过程和产品的控制。如果您希望有人为客户验证产品，那是另一个问题。@stephen
在适当的上下文中进行集成测试是客观的。这里的问题是，一些开发人员可能在不知道其原始含义的情况下劫持了该术语。甚至包括CI在内的“自动化集成测试”也应该在不同的盒子上进行；否则肯定会影响团队的其他成员。你和OP所描述的几乎是“它在我的机器上工作”，这对事情的发展毫无帮助。