The aim of this document is to briefly explain the unit and integration testing facilities that Raccoon offers above the Messaging Orientated Middleware, i.e. TIB/Rendezvous. As EAI systems become increasingly complex, we beleive that non-regression, or unit testing are a must have for the EAI team. Therefore, it is only natural that Raccoon offers these tools.
This tool is for TIB/Rendezvous what jUnit is for java with a detailed HTML report. An example of such a report can be seen here.
Like this document or not? Please tell me what you think about it at Cedric@SF.
TIB/Rendezvous is a pure asynchronous publish/subscribe implementation and the aim of the UITester tool is to provide a means of checking that a TIB/Rendezvous enabled component is behaving as expected.
We use this tool is especially to test TIB/Integration Manager sheets and ensure non regression of our work.
Unit testing of TIB enabled components is a very important feature on a daily basis for anyone working with TIB/Integration Manager, TIB/Message Broker, and so forth. So we decided we'll finally put onto Sourceforge what we've been using to test our own work.
In a general fashion, what Raccoon provides is an application that sends messages to a specific subscriber (TIB/IM in the picture) and checks for each message sent that this application generates the right message. If this isn't the case, the test fails.
The Raccoon Framework is also capable of testing other TIB enabled components such as the TIB/Adapter for
File, the main reason for this is that integration testing is also an important factor for a project.
Therefore the Raccoon Framework has to offer the capability to test a complete chain.
An UiTest is the smallest test structure available and is composed of:
An UiCase is in fact a test case scenario containing several UiTests. A test case scenario main objectif is to test a specific workflow within TIB/IM, TIB/MB, ... with messages that differ in content but not from a functional standpoint.
Putting it otherwise, an UiCase contains:
Suggested conventions - Guidelines
Within the contexte of TIB/Integration Manager, a UiCase tests a single Process diagram. Each UiTest corresponds to the messages that a Process diagram may receive.
However a UiCase is slightly more than a Process diagram because the Publisher of the UiCase corresponds to the initiating channel of the job creator that invokes the Process diagram.
A Unit is a set of UiCases for a given functional domain. The results of the test are put into an xml file that is converted in an HTML file using the "site:doc" target of Maven. An example of such a report can be seen here.
In our case we use Raccoon as follows, any ideas are welcome
For example, we use Raccoon to test the SWIFT Parser from TIBCO and our workflows related to the interpretation of SWIFT Messages.
What we have is this:
Unit: name is SWIFT_In and contains the elements provided hereafter.
UiCase: each case is related to a specific swift type, say MT541. This case contains several MT541 with different values/sequences or the tanker provided by SWIFT.
UiTest: Each test contains a specific MT, which is defined by the UiCase it belongs to, each UiTest contains a single SWIFT message and differs from the UiTest of the same UiCase by the values it bears.
This section describes how to customize the UITest tool, by default the Raccoon delivery package
contains a sample application under the
All you have to do is:
run_uitools.batand check that the path is correct.
The following elements have to be added to the classpath (already done in the file
castor-0.9.3.19-xml.jar: Castor XML tool
log4j-1.1.3.jar: Log4j tool
raccoon-0.5.2.jar: the Raccoon library
tibrvj.jar: The TIB/Rendezvous library
xerces-1.2.3.jar: The xerces parser, used by the Castor XML library and Raccoon
commons-collections-2.1.0.jar: The commons collections jakarta library
conf: the configuration directory that contains the configuration files.
raccoon.properties: the properties file for Raccoon. By default this contains:
raccoon.service.manager.mapping = data.services.xml
raccoon.service.manager.service = uitester.xml
/uitest/confunder the name
uitester.xmlYou can use this file and customize if you wish or create a new one.
An endpoint can either be a publisher or a subscriber, both types of endpoints depend on a Session element. A Session element is mainly defined by a SessionConfig component, so the first thing to do is to define this component.
A sample SessionConfig component is provided in the file
uitester.xml, it's name is
iuSessionConfig and connects to the TIB/Rendezvous daemon using the default parameters
(tcp:7500, 7500, default_NIC).
Additional configuration information is given for this component in the file
Configuring any endpoint consists in defining the component
RvSession. All this component
really needs is a
SessionConfig element. The sample
provided is named
The configuration file has only a single endpoint configuration, which means that the messages will be sent and received via the same daemon and the same UDP port.
A sample recorder component is provided and is named
UnitRecorder. This recorder will use the
iuRvSessionTestassigned to the property
tibSession. This defines the TIB/Rendezvous session on which the recorder will listen to. It is possible to define multiple TIB/Rendezvous sessions by putting assigning multiple values to the same property
<depends name="iuRvSessionTest_1" property="tibSession" type="collection"/>
<depends name="iuRvSessionTest_2" property="tibSession" type="collection"/>
<depends name="iuRvSessionTest_3" property="tibSession" type="collection"/>
<depends name="iuRvSessionTest_4" property="tibSession" type="collection"/>
tibSubjectis the subject on which the listeners will subscribe to. For example:
<defaultValue name="tibSubject" type="string" value="SwiftMessage.in" colType="collection"/>
<defaultValue name="tibSubject" type="string" value="MInstance.in" colType="collection"/>
<defaultValue name="tibSubject" type="string" value="Swift.out" colType="collection"/>
Swift.outfor all the TIB/Rendezvous subjects defined previously.
msgDir: the directory where the recorded messages will be persisted, can be relative or absolute. If the destination directory doesn't exist it will be created, if possible. If possible means that it will be created only if the last folder doesn't exist, it won't create recursively N folders.
stopSubject: the TIB/Rendezvous subject that will stop the recorder.
Using the recorder is very simple:
run_uitools.bat -record UnitRecorder. Once you get the string "
Raccoon Recorder is ready to record messages." it means that the recorder is ready.
tibrvsend raccoon.recorder.stop ""
Raccoon Recorder has stopped recording messages.
record, which was defined in the file
uitester.xmlfor the component
UnitRecorderassigned to the property
This component requires a
subscriber. The publisher
will send all the necessary messages and the subscriber will receive all the expected messages (hopefully).
In the case of the sample configuration file both elements point to the same
Furthermore you have to define the file that contains the actual configuration information, defined
by the property
testConfigFile. The sample file provided is named
and the contents are explained in the sample file.
The next element to provide is the radix of the files that will be created. It is important to bear in mind
that the Raccoon UITester persists all messages received for operator comparaison to what was expected.
These files will be stored in a special folder and the first characters of the files will be the value
You can run the tests by executing the following command:
run_uitools.bat -unit UnitTest_1 raccoon_unit.xml
Once the tests are succesfully executed the tool generates a report file under the name
raccoon_unit.xml. This file can then be converted into an HTML file using the maven:docs
target or any equivalent XML Stylesheet program (Anakia for example).
Don't forget if you're using maven to generate the documentation to copy the directory
msg folder to the same level as the generated HTML file!