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.

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)

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.

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.

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 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.

I recommend IBM RIT. it is part of IBM RTW stack. You can use it in TDD and CI/CD models of delivery easily.