我怎样才能在BizTalk中使用DDD，TDD？

Question

我刚刚开始在工作中进入BizTalk，并且希望继续使用我所了解的有关DDD，TDD等的所有内容。这是否可能或者我在创建类似的东西时总是必须使用Visio这样的编辑器管道和编排？

Answer 1

您当然可以将许多TDD和DDD的概念应用于BizTalk开发。

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

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

我是对的，你希望能够遵循测试驱动的开发方法，首先编写一个运行需求并失败的unti测试，然后编写一个满足需求并导致测试通过的方法 - 所有这些传统的编程语言，如C＃？

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

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

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

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

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

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

Mocking WebService consumed by a Biztalk Request-Response port

Answer 2

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

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

您可以找到图书馆here的简介，以及github上的完整代码。关于wiki，还有一些更详细的文档。

Answer 3

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

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

从编码的角度来看，应该在BizUnit 3.0中解决智能感知问题。缺乏XSD确实使过去很困难。我希望得到一个有助于智能感知的XSD。对于旧版本的BizUnit也有一些片段，但那些还没有更新，也许如果有时间我会给它一个去。

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

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

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

RGDS 本吉

Answer 4

您可以使用BizUnit在代码和Excel中创建和重用通用测试用例（对于功能方案）

http://www.codeplex.com/bizunit

预计BizTalk Server 2009将具有更多IDE集成可测试性。

干杯 Hemil。

Answer 5

BizUnit真的很难用，因为所有测试都是用XML而不是编程语言编写的。

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

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