作为一名BizTalk开发人员，这是我最大的烦恼之一-- BizTalk本身并不适合单元测试。事实上，BizTalk应用程序中99%的接口都是基于消息的，并且有大量可能的输入，再到编排的不透明本质，BizTalk并没有提供真实的的方法来测试功能单元。
对于BizTalk来说，集成测试往往是唯一的游戏。
由于Kevin Smith的原因，这导致了BizUnit（IMO）的错误命名。一个更好的名字可能是BizIntegrationIt。BizUnit提供了一系列帮助集成测试的工具，它的大多数测试，如检查文件是否已写入给定目录或发送HTTPRequest到BizTalk HTTPReceive位置，严格来说，都是测试集成。
现在我已经得到了这个咆哮，你所要求的是我已经思考了很长时间的东西，创建自动化单元测试的能力，给予一些真实的的信心，我做一个小的变化，Map不会突然中断其他下游，以及一种方法，以消除对外部服务的依赖。
我从来没有想过任何好的方法来做这件事，但下面是一个解决方案，应该工作，我已经做了这个孤立的每一部分的变化，但从来没有试图，但他们都在这个特定的形式在一起。
因此，如果希望模拟对某个外部服务（可能还不存在）的调用，而不需要实际进行任何外部调用**，并且**希望能够设置对该服务调用的期望并指定响应的性质，我能想到的唯一方法就是开发一个自定义适配器。

使用自定义适配器模拟Web服务

如果构建自定义请求-响应适配器，则可以将其插入发送端口以代替SOAP适配器。然后，可以为适配器指定属性，使其可以模拟Web服务。该适配器在概念上类似于环回适配器，但允许内部模拟逻辑。
您可能希望包含为适配器属性的内容：

• 所需的文档（可能是一个磁盘位置，该位置指定了您希望BizTalk应用程序发送到Web服务的内容的示例）。
• 响应文档-适配器将发送回消息传递引擎的文档。
• 测试的特定预期，例如文件元素中的查阅值。

您还可以将自定义适配器写入磁盘，并设置BizUnit步骤来验证写出的文件。
构建自定义适配器并不简单，但也有可能，您可以从BizTalk Adapter Wizard开始，并且有一篇关于部署自定义适配器here的文章。
向导生成的代码中存在错误，您需要将new Guid(""),更改为new Guid()。
还有一些在BizTalk SDK中生成自定义适配器的示例。
另一个选择是使用一个普通的http页面和HTTP请求响应，如here所述，所有的逻辑都放在http页面中。如果你喜欢http调用，并设置一个IIS端口来侦听你的测试，这可能会更简单。

初始化公寓测试

可以使用.bat文件将绑定文件导入BizTalk应用程序。
如果为运行的每个测试以及标准应用程序设置创建新的绑定文件，则可以运行相应的批处理文件来应用正确的绑定。
每个绑定文件都将更改您的Web服务发送端口以使用模拟自定义适配器，并设置该测试的特定属性。
然后，您甚至可以创建一个自定义BizUnit步骤，该步骤（可能）基于测试步骤中的设置生成绑定设置，然后运行shell命令来更新绑定。

测试消息内容

最后一件你可能需要考虑的事情，就是用某种方法测试消息的内容，你可以在模拟适配器中进行测试，但是对于大消息或者大范围的可能输入消息来说，这很快就会变得很乏味。
一种选择是创建一个自定义管道，调用Schematron来验证它接收到的文件。Schematron是一种模式语言，它允许比xsd更丰富的文件检查级别，因此您可以检查诸如“如果元素x包含此内容，我希望元素y存在”之类的内容。
如果您构建了一个自定义管道，并将schematron模式作为参数，那么您可以为特定的单元测试换入一个测试文件，验证该测试，当您调用Web服务时，您将获得一个与您所需内容实际匹配的文件（而不仅仅是与xsd匹配）

作为BizUnitExtensions（www.codeplex.com/bizunitextensions）的合著者，我同意BizUnit中的“unit”这个名字可能会让人混淆，但对于Biztalk来说，“集成测试”就是单元测试。一些Biztalk的人已经成功地使用mock来测试管道组件，并使用其他测试工具（+ BizUnit/Extensions）来测试模式和Map。
不幸的是，编排是不透明的，但这是有充分理由的。
(a)由于消息框中的巨大订阅系统-编排在被激活等时使用，因此不可能启动一些“虚拟”进程来托管编排（这可以为管道完成。Tomas Restrepo已经沿着这些路线做了一些事情）。
(b)另外，这个虚拟流程将如何处理持久性和脱水？我敢打赌，使用WF的人在尝试全面测试工作流时也会遇到同样的问题。
(c)我们不直接使用C#，因此我们无法将模拟接口“注入”到编排代码中。
(d)编排并不是真正的“单元”，它是一个复合元素。单元是进出消息框的消息，以及通过表达式形状调用的外部组件。因此，即使您可以注入模拟Web服务接口，也无法注入模拟消息框、关联集和其他内容。
对于编排，可以做的一件事是（我一直在考虑通过添加BizUnitExtensions库来实现这一点）是与OrchestrationProfiler工具链接，因为该工具提供了所有形状的详细报告，并以某种方式检查是否执行了各个步骤（也许还有执行所花的时间）。这可以在使配器更像一个白色盒方面走得很远。此外，考虑到编排调试器显示了大量变量值，肯定可以通过API获得该信息，以显示给定示例在给定点的变量值。
回到Richard的问题，我以前的开发团队有一个解决方案。基本上，我们所做的是编写一个通用的可配置HttpHandler，它解析传入的服务请求并返回预设的响应。返回的响应可以基于XPath等条件进行配置。在BUILD和DEV绑定文件中，Web服务的端点是mock。2这在将BUILD和DEV环境从实际的第三方Web服务中分离出来时非常有效。3这也有助于“合同优先”我们构建了mock，Orch开发人员使用它，而Web服务作者继续构建实际的服务。
[更新日期：2009年2月17日：此工具现在位于codeplex上：http://www.codeplex.com/mockingbird。如果这种方法听起来很有趣，请查看它，并让我知道您对该工具的看法]
现在，在有人抛出旧的“MOCK OBJECT FRAMEWORKS怎么样”之前，让我说上面的实用程序既用于Biztalk“消费者”，也用于非Biztalk消费者，但我也使用过NMock 2，发现这是一种在编写CLR消费者时模拟接口和设置期望值的极好方法。（我将很快研究MoQ和TypeMock等）。然而，由于上述原因，它不能与编排一起工作。
希望这对你有帮助。
此致！
本吉

别说了
不要对任意接口进行测试，也不要为它们创建模拟。
大多数人似乎认为开发人员（单元）测试是为了测试非平凡的、单个的功能单元，比如单个类。另一方面，对主要子系统或整个系统进行客户（验收/集成）测试也很重要。
对于Web服务，重要的功能单元隐藏在类中，这些类实际执行有意义的服务，隐藏在通信连接后面。这些类应该有单独的开发人员测试类来验证它们的功能，但完全没有任何面向Web服务的通信连接。很自然，但可能不明显，这意味着你的功能实现必须与你的连接实现分开。2所以，你的开发者（单元）测试应该永远不会看到任何特殊的通信连接;这是集成的一部分，可以（适当地）将其视为“表示”问题而不是“业务逻辑”。
客户（验收/集成）测试应该解决更大规模的功能，但仍然不关注“表示”问题。这是Facade模式的常见使用--用统一的、粗粒度的、可测试的接口公开子系统。同样，Web服务通信集成是无关紧要的，并且是单独实现的。
然而，实现一组单独的测试，实际上包括Web服务集成，这是非常有用的。端到端地测试它，这意味着构建作为Web服务客户端的测试，就像真实的的产品代码一样;它们应该以与真实的应用程序完全相同的方式使用Web服务，这意味着这些测试将作为必须实现这些应用程序的任何人（例如，如果您正在销售库，则是您的客户）的示例。
所以，为什么要这么麻烦呢？
1.您的开发人员测试验证您的功能是否在小范围内工作，而不管它是如何访问的（与表示层无关，因为它全部位于业务逻辑层内）。
1.您的客户测试将验证您的功能是否在业务逻辑层的接口边界上大范围地工作，无论如何访问它。
1.您的集成测试验证表示层是否与业务逻辑层协同工作，业务逻辑层现在是可管理的，因为您现在可以忽略底层功能（因为您在上面单独测试了它）。换句话说，这些测试侧重于漂亮的外观（GUI？）和通信接口（Web服务？）的薄层。
1.当您新增其他存取功能的方法时，您只需要针对该新的存取形式（表示层）新增整合测试。您的开发人员和客户测试可确保您的核心功能不会变更且不会中断。
1.您不需要任何特殊的工具，例如专门用于Web服务的测试工具。您使用的工具/组件/库/技术与您在生产代码中使用的完全相同。这使您的测试更有意义，因为您不是在测试其他人的工具。这为您节省了大量的时间和金钱，因为您不是在购买、部署、开发但是，如果您通过GUI进行测试（不要这样做！），您可能需要一个用于该部分的特殊工具（例如HttpUnit？）。
所以，让我们具体一点。假设我们想提供一些功能来跟踪自助餐厅的每日菜单（因为我们在一家大型公司工作，在大楼里有自己的咖啡馆，就像我的一样）。假设我们的目标是C#。
我们为菜单、菜单项和其他细粒度的功能及其相关数据构建了一些C#类。我们使用nAnt建立了一个自动构建（你这样做了，对吗？），它使用nUnit执行开发人员测试，我们确认我们可以构建一个日常菜单，并通过所有这些小片段来查看它。
我们对下一步有了一些想法，所以我们通过创建一个类来应用Facade模式，这个类公开了一些方法，同时隐藏了大多数细粒度的部分。我们添加了一组单独的客户测试，这些测试只通过新的Facade来操作，就像客户端一样。
现在，我们决定要为我们的大型企业知识工作者提供一个网页，以检查今天的自助餐厅菜单。（如果我们使用MVC，它将成为我们的模型），并部署它。由于我们已经通过客户测试彻底测试了facade类，并且由于我们的单个Web页面非常简单，我们放弃了针对Web页面编写自动测试--使用一些知识工作者的手动测试就可以了。

之后，我们开始添加一些主要的新功能，比如可以预定当天的午餐。我们扩展了细粒度的类和相应的开发者测试，因为我们知道预先存在的测试可以保护我们不破坏现有的功能。同样，我们扩展了外观类，甚至可能拆分出一个新类（例如，MenuFacade和OrderFacade），并对我们的客户测试进行类似的添加。
现在，也许，网站的改变（两个页面是一个网站，对吗？）使手动测试不能令人满意。因此，我们引入了一个类似于HttpUnit的简单工具，它允许nUnit测试网页。我们实现了一系列集成/表示测试，但针对我们的外观类的模拟版本，因为这里的要点仅仅是Web页面可以工作--我们已经知道外观类可以工作，测试通过模拟外观推送只是为了测试数据是否成功到达了另一边。仅此而已。
当然，我们的巨大成功促使首席执行官要求我们将Web应用程序暴露给mega-corp的黑莓手机。因此，我们实现了一些新的页面和一系列新的集成测试。我们不必接触开发人员或客户测试，因为我们没有添加任何新的核心功能。
最后，CTO请求（要求）我们将自助餐厅应用程序扩展到mega-corp的所有机器人员工--您在过去几天注意到他们了吗？因此，现在我们添加了一个Web服务层，通过我们的外观进行通信。同样，我们的核心功能、开发人员测试、我们通过创建类来应用Adapter/Wrapper模式，我们添加了一组新集成测试，但是它们使用普通的nUnit来创建客户端API类，这些类通过Web服务连接与服务端API类通信，服务端API类调用模拟外观类，从而确认我们的连接是否正常。
请注意，在整个过程中，除了我们的生产平台和代码、我们选择的开发平台、一些用于自动构建和测试的开源组件以及一些定义良好的测试之外，我们不需要任何重要的东西。还要注意，我们没有测试任何在生产中不使用的东西，我们也没有测试任何东西两次。
我们最终得到了一个坚实的功能核心（业务逻辑层），它已经证明了自己的成熟性（假设）。一个面向台式机的网站、一个面向BlackBerrys的网站和一个Web服务API。
现在，请原谅我的回答很长--我厌倦了不充分的回答，我不想提供一个。请注意，我实际上已经这样做了（虽然不是为了自助餐厅的菜单）。

这是一个非常有趣的问题，我还没有看到一个好的通用答案。有些人建议使用SoapUI，但我还没有时间实际测试。This page可能是有趣的。
另一种方法可能是以某种方式 Package WebDev.WebHost.dll并使用它... Phil Hakkck在this post中讨论了这一点。
之前在SO here上也讨论过。
如果您找到其他解决方案，请告诉我们！

这是一种方法：
回到Richard的问题，我以前的开发团队有一个解决方案。基本上，我们所做的是编写一个通用的可配置HttpHandler，它解析传入的服务请求并返回预设的响应。

我已经有一段时间没有这样做了，但是当我测试我的Biztalk应用程序时，我总是使用soap ui或web service studio，我能够毫不费力地测试不同的输入值。