For BW projects, I cooked my own Unit Test framework based on BW Processes itself. So the automated tests and validations are coded in the TIBCO project itself.
For AMX projects I recommend SOAPUI for automated testing of your services. However, I coded all the unit tests in the underlying language, in my case Java, using JUnit. The Implementation classes under the components reference each other directly in the unit tests, bypassing the AMX code doing the messaging.
I've had great success creating a soap interface layer for each of my processes (taking in the same arguments) and leveraging SoapUI to do all the testing driven from a few database tables.
Edit:
What I described is pretty much how BWUnit is working: it creates a web service interface around each of your processes (maybe with a little less manual work, but same concept.)
Test Input (SoapUI) -> Testable Interface (soap/ems/etc) -> Existing process -> Exit Interface -> Assertions (SoapUI)
You could do the testing within tibco itself, with files, RV, JMS, or any input for that matter, except you're writing all the test assertion code yourself rather than using an existing tool that has it all built in. You can then rely on SoapUI to generate all your JUnit reports etc.
If you want to get really fancy, you can add a soapui target to your build script to include the unit tests and/or functional tests for each build once it's deployed.
Deopends on the protocol used (what is used). Racoon and SoapUI has been mentioned. With them you can test on a "per module" level. That is Component or System tests. Especially usful for performance tests. However this is the most common way to test tibco components.
I will have a look at the BWUnit, looks interesting and integrated with CI Servers (I have built a similar tool in a project). A flaw of this approch may be that TIBCO systems usually are composed of different tools and not only BW, this means that Java components, C++ servers and so fort is used to for the total system.
Trying to do a methodology like TDD using soap UI would not be very effective. I have used This for BW and you do not get the same level of granularity and comfort from a full unit test suite. BWUnit is a good tool, and if you have a good relationship with your TIbco PSG guys you may be able to get TibUnit which is a PSG Ware like CLE.
We've also come up with a plan to use an external Unit test framework like .net and then use a controller pattern to swap out processes using Dynamic Process override flag. So esentaially we'd have a control channel that would say something like
Control - Process 1 Override -/Processes/SomeProcess.process - Process 2 Override {Blank}
so in your unit test you would be able in your setup to call BW using your control channel (EMS or HTTP) and tell it to load a different process. While this works its still a hack because of the limited functionality of Designer.
We've also looked at Service Grid and BWSE and that didn't appear to give us anything more. Actually a little more limiting.
发布评论
评论（8）
对于 BW 项目，我基于 BW Processes 本身编写了自己的单元测试框架。因此，自动化测试和验证是在 TIBCO 项目本身中进行编码的。
对于 AMX 项目，我建议使用 SOAPUI 来自动测试您的服务。不过，我使用 JUnit 用底层语言（在我的例子中是 Java）编写了所有单元测试。组件下的实现类在单元测试中直接相互引用，绕过执行消息传递的 AMX 代码。
For BW projects, I cooked my own Unit Test framework based on BW Processes itself. So the automated tests and validations are coded in the TIBCO project itself.
For AMX projects I recommend SOAPUI for automated testing of your services. However, I coded all the unit tests in the underlying language, in my case Java, using JUnit. The Implementation classes under the components reference each other directly in the unit tests, bypassing the AMX code doing the messaging.
我在为每个进程创建一个soap接口层（采用相同的参数）并利用 SoapUI 方面取得了巨大成功完成从几个数据库表驱动的所有测试。
编辑：
我所描述的基本上是 BWUnit 的工作方式：它围绕每个流程创建一个 Web 服务接口（可能需要更少的手动工作，但概念相同。）
您可以在 tibco 本身内使用文件、RV、JMS 或任何与此相关的输入进行测试，除非您自己编写所有测试断言代码，而不是使用内置所有代码的现有工具然后，您可以依靠 SoapUI 来生成所有 JUnit 报告等。
如果您想变得非常奇特，您可以将soapui 目标添加到构建脚本中，以在部署后包含每个构建的单元测试和/或功能测试。
I've had great success creating a soap interface layer for each of my processes (taking in the same arguments) and leveraging SoapUI to do all the testing driven from a few database tables.
Edit:
What I described is pretty much how BWUnit is working: it creates a web service interface around each of your processes (maybe with a little less manual work, but same concept.)
You could do the testing within tibco itself, with files, RV, JMS, or any input for that matter, except you're writing all the test assertion code yourself rather than using an existing tool that has it all built in. You can then rely on SoapUI to generate all your JUnit reports etc.
If you want to get really fancy, you can add a soapui target to your build script to include the unit tests and/or functional tests for each build once it's deployed.
取决于所使用的协议（使用什么）。已经提到了 Racoon 和 SoapUI。使用它们，您可以在“每个模块”级别上进行测试。那是组件或系统测试。对于性能测试特别有用。然而，这是测试 tibco 组件的最常见方法。
我将看看 BWUnit，看起来很有趣并且与 CI 服务器集成（我在项目中构建了类似的工具）。这种方法的一个缺陷可能是TIBCO系统通常由不同的工具组成，而不仅仅是BW，这意味着Java组件、C++服务器等用于整个系统。
还有一个名为 GHTester 的商业工具 (http://www.greenhatconsulting.com/ghtester/ ）
如果您使用 RV，您可以查看 http://www.rvsnoop.org/免费捕获可重播格式的消息（我启动的 OSS 工具）
Deopends on the protocol used (what is used). Racoon and SoapUI has been mentioned. With them you can test on a "per module" level. That is Component or System tests. Especially usful for performance tests. However this is the most common way to test tibco components.
I will have a look at the BWUnit, looks interesting and integrated with CI Servers (I have built a similar tool in a project). A flaw of this approch may be that TIBCO systems usually are composed of different tools and not only BW, this means that Java components, C++ servers and so fort is used to for the total system.
There is also a Commercial tool called GHTester (http://www.greenhatconsulting.com/ghtester/)
If you are using RV you might have a look at http://www.rvsnoop.org/ to capture the messages in a replayable format for free (OSS tool that I started)
尝试使用soap UI 来实现像TDD 这样的方法不会很有效。我已将 This 用于 BW，但您无法从完整的单元测试套件中获得相同级别的粒度和舒适度。 BWUnit 是一个很好的工具，如果您与 TIbco PSG 人员关系良好，您也许可以获得 TibUnit，它是一个像 CLE 一样的 PSG Ware。
我们还提出了一个计划，使用外部单元测试框架（如 .net），然后使用控制器模式使用动态进程覆盖标志来交换进程。所以本质上我们会有一个控制通道，它会显示类似
Control 的 内容
- 进程 1 覆盖
-/Processes/SomeProcess.process
- 进程2覆盖
{Blank}
，因此在单元测试中，您可以在设置中使用控制通道（EMS 或 HTTP）调用 BW，并告诉它加载不同的进程。虽然这有效，但由于 Designer 的功能有限，它仍然是一种黑客手段。
我们还研究了服务网格和 BWSE，但这似乎并没有给我们带来更多信息。实际上限制更多一些。
Trying to do a methodology like TDD using soap UI would not be very effective. I have used This for BW and you do not get the same level of granularity and comfort from a full unit test suite. BWUnit is a good tool, and if you have a good relationship with your TIbco PSG guys you may be able to get TibUnit which is a PSG Ware like CLE.
We've also come up with a plan to use an external Unit test framework like .net and then use a controller pattern to swap out processes using Dynamic Process override flag. So esentaially we'd have a control channel that would say something like
Control
- Process 1 Override
-/Processes/SomeProcess.process
- Process 2 Override
{Blank}
so in your unit test you would be able in your setup to call BW using your control channel (EMS or HTTP) and tell it to load a different process. While this works its still a hack because of the limited functionality of Designer.
We've also looked at Service Grid and BWSE and that didn't appear to give us anything more. Actually a little more limiting.
有一个名为 Raccoon 的旧框架，构建于 Tibco ActiveEnterprise 之上。
它有一个名为 UiTest 的单元测试组件，专注于 RendezVous 消息传递。
不过最近好像没有太多活动。
There's an old framework called Raccoon built above Tibco ActiveEnterprise.
It has a component for unit testing called UiTest focused on RendezVous messaging.
It doesn't seem to have too much activity lately, though.
通过 BW-TEST，您可以练习 TDD 并将项目添加到 CI 中
在 http://nicosommi.com/?p=209 上查看
它是开源的
With BW-TEST you can practice TDD and add your projects to your CI
Check it out on http://nicosommi.com/?p=209
It's open source
IBM RIT< /a> 是处理此类场景的非常好的工具，它可以帮助您断言不同的场景并评估代码覆盖率。
IBM RIT is very good tool to work on this kind of scenarios, it can help you to assert different scenarios and also to evaluate code coverage.
我推荐 IBM RIT。它是 IBM RTW 堆栈的一部分。您可以轻松地在 TDD 和 CI/CD 交付模型中使用它。
I recommend IBM RIT. it is part of IBM RTW stack. You can use it in TDD and CI/CD models of delivery easily.