我刚开始在工作中接触 BizTalk,并希望继续使用我学到的关于 DDD、TDD 等的所有知识。这是否可能,或者我在创建管道和编排之类的东西时总是必须使用类似 Visio 的编辑器?
5 回答
您当然可以将很多 TDD 和 DDD 的概念应用到 BizTalk 开发中。
您可以围绕域对象的概念进行设计和开发(尽管在 BizTalk 和集成开发中,我经常发现接口对象或契约优先设计是一种更有用的思维方式——什么消息在我的接口中传递)。您还可以遵循 TDD 的“构建最简单的可行的东西”和“只构建使测试通过的东西”的理念。
但是,您的问题听起来像是在询问更多关于这些设计和开发方法的以代码为中心的方面。
我是否正确,您希望能够遵循测试驱动的开发方法,首先编写一个运行需求并失败的 unti 测试,然后编写一个满足需求并导致测试通过的方法——所有这些都在传统的编程中像 C# 这样的语言?
不幸的是,答案是否定的。大多数 BizTalk 工件(管道、映射、编排......)只能使用 Visual Studio BizTalk 插件真正构建。有很多方法可以查看底层的 c# 代码,但永远不会想尝试直接开发此代码。
有两个工具BizUnit和BizUnit Extensions提供了一些能力来控制 BizTalk 应用程序的执行和测试它们,但这实际上只能让您执行更多受控和更多测试驱动的集成测试。
您拖到编排设计图面上的形状在很大程度上只是作为一个不透明的执行单元来完成它们的工作。以及编排、管道、地图等……所有这些东西主要是为了在整个 BizTalk 解决方案中执行(和测试)。
良好的设计实践(从 TDD 等方法中获得指导)将导致将 BizTalk 解决方案分解为更小、更模块化和可测试的块,并且有一些方法可以单独测试管道之类的东西。
但遗憾的是,代码中 TDD 和 DDD 的详细细节没有翻译。
对于一些可能有用的相关讨论,请参阅此问题:
如果您经常在 BizTalk 中使用管道和自定义管道组件,您可能会发现我自己的 PipelineTesting 库很有用。它允许您使用 NUnit(或您喜欢的任何其他测试框架)为完整的管道、特定的管道组件甚至模式(例如平面文件模式)创建自动化测试。
如果您使用这种功能,它非常有用,如果我自己可以这么说的话(我在自己的项目中大量使用它)。
您可以在此处找到对该库的介绍,以及在github上的完整代码。它的wiki上还有一些更详细的文档。
我同意 CKarras 的评论。许多人认为这是他们不喜欢 BizUnit 框架的原因。但是看看 BizUnit 3.0。它有一个对象模型,允许您用 C#/VB 而不是 XML 编写整个测试步骤。BizUnitExtensions 也正在升级到新的对象模型。
基于 XML 的系统的优点是更容易生成测试步骤,更新步骤时无需重新编译。在我自己的扩展库中,我发现 XmlPokeStep(受 NAnt 启发)非常有用。我的团队可以即时更新测试步骤 xml。例如,假设我们必须调用一个创建客户记录的 Web 服务,然后检查数据库中的相同记录。现在,如果 Web 服务返回 ID(动态生成),我们可以即时更新下一步的测试步骤(当然不在同一个 xml 文件中),然后使用它来检查数据库。
从编码的角度来看,智能感知现在应该在 BizUnit 3.0 中得到解决。过去,缺少 XSD 确实让事情变得困难。我希望得到一个有助于智能感知的 XSD。旧版本的 BizUnit 也有一些片段,但这些片段尚未更新,也许如果有时间我会试一试。
但回到 TDD 问题,如果您了解 TDD 背后的一些意图 - 规范或行为驱动元素,那么您也可以在一定程度上将其应用于 Biztalk 开发,因为 BizTalk 很大程度上基于合同驱动的开发。因此,您可以先指定接口并创建存根编排等来处理它们,然后构建核心。那时您可以编写 BizUnit 测试。我希望有一些工具可以自动化这个过程,但现在还没有。
使用诸如 ESB 指南之类的框架还可以帮助您提供一个基础平台,以便您可以通过您的系统迭代地实现主要用例。
Just a few thoughts. Hope this helps. I think its worth blogging about more extensively. This is a good topic to discuss.Do ping me if you have any questions or we can always discuss more over here.
Rgds Benjy
您可以使用 BizUnit 在代码和 excel 中创建和重用通用测试用例(用于功能场景)
http://www.codeplex.com/bizunit
BizTalk Server 2009 有望具有更多的 IDE 集成可测试性。
干杯赫米尔。
BizUnit 使用起来确实很痛苦,因为所有测试都是用 XML 而不是编程语言编写的。
在我们的项目中,我们将 BizUnit 的部分“移植”到了一个普通的旧 C# 测试框架。这允许我们直接在 C# NUnit/MSTest 代码中使用 BizUnit 的步骤库。这使得测试更容易编写(使用 VS Intellisense),更灵活,最重要的是,在测试失败的情况下更容易调试。这种方法的主要缺点是我们从主要的 BizUnit 源分叉。
对于未来的项目,我会考虑的另一个有趣的选择是BooUnit,它是 BizUnit 之上的 Boo 包装器。它具有类似于我们的 BizUnit“端口”的优点,但也具有仍然使用 BizUnit 而不是从中分叉的优点。