如何在 BizTalk 中仍然使用 DDD、TDD？答案

【问题标题】：How can I still use DDD, TDD in BizTalk?如何在 BizTalk 中仍然使用 DDD、TDD？
【发布时间】：2010-09-22 02:51:35
【问题描述】：

我刚开始在工作中使用 BizTalk，我很想继续使用我所学到的关于 DDD、TDD 等的所有知识。这是否可能，或者我在创建诸如此类的东西时总是必须使用类似 Visio 的编辑器管道和编排？

【问题讨论】：

标签： agile domain-driven-design biztalk middleware testdrivendesign

【解决方案1】：

我同意 CKarras 的 cmets。许多人认为这是他们不喜欢 BizUnit 框架的原因。但是看看 BizUnit 3.0。它有一个对象模型，允许您用 C#/VB 而不是 XML 编写整个测试步骤。 BizUnitExtensions 也正在升级到新的对象模型。

基于 XML 的系统的优点是更容易生成测试步骤，更新步骤时无需重新编译。在我自己的扩展库中，我发现 XmlPokeStep（受 NAnt 启发）非常有用。我的团队可以即时更新测试步骤 xml。例如，假设我们必须调用创建客户记录的 Web 服务，然后检查数据库中的相同记录。现在，如果 Web 服务返回 ID（动态生成），我们可以即时更新下一步的测试步骤（当然不在同一个 xml 文件中），然后使用它来检查数据库。

从编码的角度来看，智能感知现在应该在 BizUnit 3.0 中得到解决。过去，缺少 XSD 确实让事情变得困难。我希望得到一个有助于智能感知的 XSD。旧版本的 BizUnit 也有一些 sn-ps，但这些还没有更新，也许如果有时间我会试一试。

但是回到 TDD 问题，如果您了解 TDD 背后的一些意图 - 规范或行为驱动元素，那么您也可以在一定程度上将其应用于 Biztalk 开发，因为 BizTalk 很大程度上基于合同驱动的开发.因此，您可以首先指定您的接口并创建存根编排等来处理它们，然后构建核心。那时您可以编写 BizUnit 测试。我希望有一些工具可以自动化这个过程，但现在还没有。

使用诸如 ESB 指南之类的框架还可以帮助您提供一个基础平台，以便您可以通过您的系统迭代地实施主要用例。

只是一些想法。希望这可以帮助。我认为它值得更广泛地写博客。这是一个很好的讨论话题。如果您有任何问题，请联系我，或者我们随时可以在这里讨论更多。

Rgds 本杰

【讨论】：

【解决方案2】：

BizUnit 使用起来确实很痛苦，因为所有测试都是用 XML 而不是编程语言编写的。

在我们的项目中，我们将 BizUnit 的部分“移植”到了一个普通的旧 C# 测试框架。这允许我们直接在 C# NUnit/MSTest 代码中使用 BizUnit 的步骤库。这使得测试更容易编写（使用 VS Intellisense），更灵活，最重要的是，在测试失败的情况下更容易调试。这种方法的主要缺点是我们从主要的 BizUnit 源中分叉。

对于未来的项目，我会考虑的另一个有趣的选项是BooUnit，它是 BizUnit 之上的 Boo 包装器。它具有类似于我们的 BizUnit“端口”的优点，但也具有仍然使用 BizUnit 而不是从中分叉的优点。

【讨论】：

【解决方案3】：

如果您经常在 BizTalk 中使用管道和自定义管道组件，您可能会发现我自己的 PipelineTesting 库很有用。它允许您使用 NUnit（或您喜欢的任何其他测试框架）为完整的管道、特定的管道组件甚至模式（例如平面文件模式）创建自动化测试。

如果你使用这种功能会非常有用，如果我自己可以这么说的话（我在自己的项目中大量使用它）。

您可以在here 上找到库的介绍，以及在github 上的完整代码。在其wiki 上还有一些更详细的文档。

【讨论】：

【解决方案4】：

您可以使用 BizUnit 在代码和 excel 中创建和重用通用测试用例（用于功能场景）

http://www.codeplex.com/bizunit

BizTalk Server 2009 有望具有更多的 IDE 集成可测试性。

干杯赫米尔。

【讨论】：

【解决方案5】：

您当然可以将很多 TDD 和 DDD 的概念应用到 BizTalk 开发中。

您可以围绕域对象的概念进行设计和开发（尽管在 BizTalk 和集成开发中，我经常发现接口对象或契约优先设计是一种更有用的思维方式 - 什么消息在我的接口中传递）。您还可以遵循 TDD 的“构建最简单可行的东西”和“只构建使测试通过的东西”的理念。

但是，您的问题听起来像是在询问更多关于这些设计和开发方法以代码为中心的方面。

您是否希望能够遵循测试驱动的开发方法：首先编写一个运行需求但失败的 unti 测试，然后编写一个满足需求并导致测试通过的方法 - 所有这些都在像 C# 这样的传统编程语言？

不幸的是，答案是否定的。大多数 BizTalk 工件（管道、映射、编排......）只能使用 Visual Studio BizTalk 插件真正构建。有很多方法可以查看底层 c# 代码，但永远不会想尝试直接开发此代码。

有两个工具 BizUnit 和 BizUnit Extensions 可以控制 BizTalk 应用程序的执行并对其进行测试，但这实际上只能让您执行更多控制和更多测试驱动的集成测试。

您拖到编排设计图面上的形状在很大程度上只是作为一个不透明的执行单元来完成它们的工作。以及编排、管道、地图等......所有这些东西主要是为了在整个 BizTalk 解决方案中执行（和测试）。

良好的设计实践（从 TDD 等方法中获得指导）将导致将 BizTalk 解决方案分解为更小、更模块化和可测试的块，并且有一些方法可以单独测试管道之类的东西。

但遗憾的是，代码中 TDD 和 DDD 的详细细节没有翻译。

对于一些可能有用的相关讨论，请参阅此问题：

Mocking WebService consumed by a Biztalk Request-Response port

【讨论】：

非常感谢您的回答。我很高兴有诸如 BizUnit 和 BizUnit 扩展之类的东西。我会试一试。