问题描述
我正在使用 BizUnit 来对我的Biztalk编排进行单元测试.编排消耗了一个WebService,对它们进行测试似乎更像是集成测试而不是单元测试.
I'm using BizUnit to unit-tests my Biztalk orchestrations, but some orchestrations consume a WebService,and testing these seems more like integration testing than unit testing.
我熟悉使用模拟框架模拟生成的代理对象,以便从Windows Forms应用程序测试Web服务,但是我希望能够在请求中以更集成的方式进行操作-响应端口?
I'm familiar with using a mocking framework to mock the generated proxy objects, in order to test a web service from a Windows Forms application, but I would like to be able to do it in a more integrated way in a request-response port?
您将如何解决这个问题?
How would you approach this problem?
推荐答案
作为BizTalk开发人员,这是我主要的烦恼之一-BizTalk不会将其用于单元测试.从您进入BizTalk应用程序的接口的99%事实上都是基于消息的,并且具有大量可能的输入,再到业务流程的不透明性质,BizTalk并没有提供测试功能单元的真正方法.单位.
This goes to the heart of one of my main irritations as a BizTalk developer - BizTalk does not lend it self to unit testing. From the fact the 99% of your interfaces into BizTalk applications are message based and have a huge number of possible inputs, through to the opaque nature of orchestrations, BizTalk offers no real way of testing units of functionality as... well... units.
对于BizTalk,可悲的是,集成测试通常是市面上唯一的游戏.
For BizTalk, integration tests are sadly often the only game in town.
由于凯文·史密斯(Kevin Smith)的过错,这导致BizUnit(IMO)被误用.更好的名称可能是BizIntegrationIt. BizUnit提供了一系列工具,可以帮助进行集成测试(大部分测试),例如检查文件是否已写入给定目录或将HTTPRequest发送到BizTalk HTTPReceive位置,严格来说都是在测试集成.
That results in, due to no fault on the part of Kevin Smith, BizUnit being (IMO) a misnomer. A better name would perhaps be BizIntegrationIt. BizUnit offers a range of tools that assist in integration testing, the majority of its tests, like checking if a file has been written to a given directory or sending an HTTPRequest to a BizTalk HTTPReceive location are all strictly speaking, testing integration.
现在,我已经大声疾呼了,您所要的是我已经考虑了很长时间的东西,能够创建自动化的单元测试,这使我真正有信心在我的小小的改变上地图不会突然破坏下游的其他内容,以及消除对外部服务的依赖的方法.
Now that I've gotten that rant out, what you are asking for is something I've been thinking about for a long time, the ability to create automated unit tests that give some real confidence that my making a small change to a map won't suddenly break something else downstream, as well as a way to remove dependance on external services.
我从来没有想过这样做的任何好方法,但是下面是一个应该可以工作的解决方案,我已经单独完成了每个部分的变体,但从未尝试过将它们全部一起以这种特定形式.
I've never thought of any nice way of doing this but below is a solution that should work, I've done variations of each part of this in isolation but never tried to but them all together in this specific form.
因此,由于需要模拟对某个外部服务(可能甚至不存在)的呼叫,而无需实际进行任何外部呼叫 ,并且希望能够设置对该服务的期望调用并指定响应的性质,我唯一想到的方法就是开发自定义适配器.
So given the desire to mock a call to some external service (that may not even exist yet) without needing to actually make any external call and wanting to have the ability to set expectations for that service call and to specify the nature of the response, the only method I can think of is to develop a custom adapter.
如果您构建定制的请求-响应适配器,则可以将其插入到您的发送端口中,以代替SOAP适配器.然后,您可以为适配器指定属性,以使其能够模拟Web服务.该适配器在概念上与回送适配器类似,但是将允许内部模拟逻辑.
If you build a custom request-response adapter you can plug it into your send port in place of the SOAP adapter. You can then specify properties for the adapter that allow it to behave as a mock of your webservice. The adapter would be similar in concept to a loopback adapter but would allow internal mocking logic.
您可能希望包含为适配器属性的内容
Things that you might want to include as adapter properties:
- 期望的文档(也许是一个磁盘位置,它指定您希望BizTalk应用程序发送到Web服务的示例).
- 响应文档-适配器将发送回消息传递引擎的文档.
- 对测试的特定期望,例如文档元素中的查找值.
您还可以将自定义适配器写入磁盘,并设置BizUnit步骤以验证已写出的文件.
You could also have the custom adapter write to disk and setup a BizUnit step to validate the file that was written out.
构建自定义适配器并非易事,但可以的话,您可以从 BizTalk适配器向导中获得一个良好的开端. ,并且在此处中,有一篇有关部署自定义适配器的文章.
Building a custom adapter is non-trivial, but possible, you can get a good start from the BizTalk Adapter Wizard and there is an article on deploying custom adapters here.
向导生成的代码中存在错误,您需要将new Guid(""),
更改为new Guid()
.
There is a bug in the code generated by the wizard, you will need to change new Guid(""),
to new Guid()
.
还有一些在BizTalk SDK中构建自定义适配器的示例.
There are also some examples of building custom adapters in the BizTalk SDK.
另一种选择是使用纯HTTP页面和HTTP请求响应,如此处,您所有的逻辑都将放在http页面中.如果您愿意进行http调用并设置IIS端口以监听您的测试,则这可能会更简单.
Another option is to use a plain http page and the HTTP solicit response as discussed here, all your logic goes in the http page. This is probably simpler if you are happy having an http call, and setting up an IIS port to listen for your test.
您可以使用.bat文件将绑定文件导入BizTalk应用程序.
You can import binding files into a BizTalk application using a .bat file.
如果您为运行的每个测试以及标准应用程序设置了新的绑定文件,则可以运行适当的批处理文件以应用正确的绑定.
If you make a new binding file for each test you run, as well as for your standard applicaiton set up, you can then run the appropriate batch file to apply the right binding.
每个绑定文件都会更改您的Web服务发送端口,以使用模拟自定义适配器并设置该测试的特定属性.
Each binding file would change your webservice sendport to use the mock custom adapter and set the specific properties for that test.
您甚至可以执行一个自定义BizUnit步骤,该步骤(也许)基于测试步骤中的设置生成绑定设置,然后运行shell命令以更新绑定.
You could then even make a custom BizUnit step that (perhaps) generated binding settings based on settings in the test step and then ran the shell commands to update the bindings.
您可能要考虑的最后一件事,是将所有这些真正地联系在一起,是一种测试消息内容的方法.您可以在模拟适配器中执行此操作,但是对于大型消息或大量可能的输入消息,这将很快变得很乏味.
A final thing that you might want to consider, to really tie all this together, is some way of testing the contents of messages. You could do this in your mock adapter, but that would get tedious very quickly for large messages, or for a large range of possible input messages.
一种选择是制作一个自定义管道,该管道调用 Schematron 来验证接收到的文件. Schematron是一种架构语言,它允许对xsd进行更丰富的文件检查,因此您可以检查诸如如果元素x包含此内容,我希望元素y存在"之类的东西.
One option is to make a custom pipeline that calls Schematron to validate files that it receives. Schematron is a schema language that allows a much richer level of file inspection that xsd, so you can check things like "If element x contains this content, I expect element y to be present".
如果您构建了一个以schematron模式作为参数的自定义管道,则可以在测试文件中交换特定的单元测试,从而对此测试进行验证,当您调用Web服务时,您会得到一个与实际匹配的文件您想要什么(不仅与xsd相符)
If you built a custom pipeline that took a schematron schema as a parameter, you could then swap in a testing file for a specific unit test, validating that for this test, when you call the webservice you get a file that actually matches what you want (and doesn't just match the xsd)
这篇关于模拟Biztalk请求-响应端口占用的WebService的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!