如何在 BizTalk 中仍然使用 DDD、TDD？
我刚刚开始在工作中使用 BizTalk，并且希望继续使用我学到的有关 DDD、TDD 等的所有知识。这是否可能，或者在创建管道和编排等内容时我是否总是必须使用 Visio 之类的编辑器？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我刚刚开始在工作中使用 BizTalk，并且希望继续使用我学到的有关 DDD、TDD 等的所有知识。这是否可能，或者在创建管道和编排等内容时我是否总是必须使用 Visio 之类的编辑器？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
您当然可以将 TDD 和 DDD 的很多概念应用到 BizTalk 开发中。
您可以围绕域对象的概念进行设计和开发（尽管在 BizTalk 和集成开发中，我经常发现接口对象或契约优先设计是一种更有用的思维方式 - 哪些消息在我的接口上传递）。 您还可以遵循 TDD 的“构建最简单、可行的东西”和“仅构建使测试通过的东西”的理念。
然而，您的问题听起来像是您更多地询问这些设计和开发方法以代码为中心的方面。
我是否正确，您希望能够遵循测试驱动开发方法，首先编写一个执行需求但失败的 unti 测试，然后编写一个满足需求并导致测试通过的方法 - 所有这些都在传统编程中像 C# 这样的语言？
不幸的是，答案是否定的。 大多数 BizTalk 工件（管道、映射、编排...）只能使用 Visual Studio BizTalk 插件真正构建。 有多种方法可以查看底层 C# 代码，但人们永远不会想尝试直接开发此代码。
有两个工具 BizUnit 和 BizUnit 扩展 提供了一些控制 BizTalk 应用程序的执行并测试它们的能力，但这实际上只能让您执行更多受控和更多测试驱动的集成测试。
您拖到 Orchestration 设计界面上的形状在很大程度上只是作为一个不透明的执行单元来完成其任务。 编排、管道、映射等...所有这些东西主要是为了在整个 BizTalk 解决方案中执行（和测试）。
良好的设计实践（借鉴 TDD 等方法）将导致将 BizTalk 解决方案分解为更小、更模块化和可测试的块，并且是否有方法可以单独测试管道等事物。
但遗憾的是，代码中 TDD 和 DDD 的详细细节无法翻译。
有关一些可能有用的相关讨论，请参阅此问题：
Biztalk 请求-响应端口消耗的模拟 WebService
You can certainly apply a lot of the concepts of TDD and DDD to BizTalk development.
You can design and develop around the concept of domain objects (although in BizTalk and integration development I often find interface objects or contract first design to be a more useful way of thinking - what messages get passed around at my interfaces). And you can also follow the 'Build the simplest possible thing that will work' and 'only build things that make tests pass' philosophies of TDD.
However, your question sounds like you are asking more about the code-centric sides of these design and development approaches.
Am I right that you would like to be able to follow the test driven development approach of first writing a unti test that exercises a requirement and fails, then writing a method that fulfils the requirement and causes the test to pass - all within a traditional programing language like C#?
For that, unfortunately, the answer is no. The majority of BizTalk artifacts (pipelines, maps, orchestrations...) can only really be built using the Visual Studio BizTalk plugins. There are ways of viewing the underlying c# code, but one would never want to try and directly develop this code.
There are two tools BizUnit and BizUnit Extensions that give some ability to control the execution of BizTalk applications and test them but this really only gets you to the point of performing more controled and more test driven integration tests.
The shapes that you drag onto the Orchestration design surface will largely just do their thing as one opaque unit of execution. And Orchestrations, pipelines, maps etc... all these things are largely intended to be executed (and tested) within an entire BizTalk solution.
Good design practices (taking pointers from approaches like TDD) will lead to breaking BizTalk solutions into smaller, more modular and testable chunks, and are there are ways of testing things like pipelines in isolation.
But the detailed specifics of TDD and DDD in code sadly don't translate.
For some related discussion that may be useful see this question:
Mocking WebService consumed by a Biztalk Request-Response port
如果您经常在 BizTalk 中使用管道和自定义管道组件，您可能会发现我自己的 PipelineTesting 库很有用。 它允许您使用 NUnit（或您喜欢的任何其他测试框架）为完整管道、特定管道组件甚至模式（例如平面文件模式）创建自动化测试。
如果您使用这种功能，它非常有用，如果我自己可以这么说的话（我在自己的项目中大量使用它）。
您可以在此处找到该库的介绍，以及完整代码位于 github。 其 wiki 上还有一些更详细的文档。
If you often make use of pipelines and custom pipeline components in BizTalk, you might find my own PipelineTesting library useful. It allows you to use NUnit (or whatever other testing framework you prefer) to create automated tests for complete pipelines, specific pipeline components or even schemas (such as flat file schemas).
It's pretty useful if you use this kind of functionality, if I may say so myself (I make heavy use of it on my own projects).
You can find an introduction to the library here, and the full code on github. There's also some more detailed documentation on its 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 指南等框架还可以帮助您提供一个基础工作平台，以便您可以通过系统迭代地实现主要用例。
只是一些想法。 希望这可以帮助。 我认为值得在博客上更广泛地讨论它。
这是一个值得讨论的好话题。如果您有任何疑问，请联系我，或者我们随时可以在这里讨论更多内容。
参考值
班吉
I agree with the comments by CKarras. Many people have cited that as their reason for not liking the BizUnit framework. But take a look at BizUnit 3.0. It has an object model that allows you to write the entire test step in C#/VB instead of XML. BizUnitExtensions is being upgraded to the new object model as well.
The advantages of the XML based system is that it is easier to generate test steps and there is no need to recompile when you update the steps. In my own Extensions library, I found the XmlPokeStep (inspired by NAnt) to be very useful. My team could update test step xml on the fly. For example, lets say we had to call a webservice that created a customer record and then checked a database for that same record. Now if the webservice returned the ID (dynamically generated), we could update the test step for the next step on the fly (not in the same xml file of course) and then use that to check the database.
From a coding perspective, the intellisense should be addressed now in BizUnit 3.0. The lack of an XSD did make things difficult in the past. I'm hoping to get an XSD out that will aid in the intellisense. There were some snippets as well for an old version of BizUnit but those havent been updated, maybe if theres time I'll give that a go.
But coming back to the TDD issue, if you take some of the intent behind TDD - the specification or behavior driven element, then you can apply it to some extent to Biztalk development as well because BizTalk is based heavily on contract driven development. So you can specify your interfaces first and create stub orchestrations etc to handle them and then build out the core. You could write the BizUnit tests at that time. I wish there were some tools that could automate this process but right now there arent.
Using frameworks such as the ESB guidance can also help give you a base platform to work off so you can implement the major use cases through your system iteratively.
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 集成可测试性。
干杯
赫米尔。
You could use BizUnit to create and reuse generic test cases both in code and excel(for functional scenarios)
http://www.codeplex.com/bizunit
BizTalk Server 2009 is expected to have more IDE integrated testability.
Cheers
Hemil.
BizUnit 使用起来确实很痛苦，因为所有测试都是用 XML 而不是编程语言编写的。
在我们的项目中，我们将 BizUnit 的部分内容“移植”到了普通的旧式 C# 测试框架中。 这允许我们直接在 C# NUnit/MSTest 代码中使用 BizUnit 的步骤库。 这使得测试更容易编写（使用 VS Intellisense）、更灵活，最重要的是，在测试失败时更容易调试。 这种方法的主要缺点是我们从主要的 BizUnit 源中分叉出来。
我会为未来的项目考虑的另一个有趣的选择是 BooUnit，它是 BizUnit 之上的 Boo 包装器。 它具有与我们的 BizUnit“移植”类似的优点，但也具有仍然使用 BizUnit 而不是从中分叉的优点。
BizUnit is really a pain to use because all the tests are written in XML instead of a programming language.
In our projects, we have "ported" parts of BizUnit to a plain old C# test framework. This allows us to use BizUnit's library of steps directly in C# NUnit/MSTest code. This makes tests that are easier to write (using VS Intellisense), more flexible, and most important, easier to debug in case of a test failure. The main drawback of this approach is that we have forked from the main BizUnit source.
Another interesting option I would consider for future projects is BooUnit, which is a Boo wrapper on top of BizUnit. It has advantages similar to our BizUnit "port", but also has the advantage of still using BizUnit instead of forking from it.