Browse Prior Art Database

A pattern for system testing messaging and other network based products Disclosure Number: IPCOM000182078D
Original Publication Date: 2009-Apr-24
Included in the Prior Art Database: 2009-Apr-24
Document File: 4 page(s) / 119K

Publishing Venue



In Enterprise integration the problems have been around integration of products or components and when instances are spread across multiple system. For example, network issues cause software failure and FDCs. With automation being the applied to all testing that is done, these scenarios usually get missed out due to complexity of testing and automation.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

A pattern for system testing messaging and other network based products


Neeraj Krishna, Vijay R Kalangumvathakkal

Solution is built over the following principles:
1. The test script need not have any knowledge of test machine that run different instances of software

No manual intervention for the execution of test

3. Ability to cause multiple events on different test machines at the same time (Asynchronous)


1. Easier automation of complex tests involving multiple machines
2. If MQTT is used for Publish/Subscribe the subscribers can run on any system and hence will allow small devices also to become a part of the test easily
3. Decouple Test code from the test infrastructure
4. Improve change and extensibility in test infrastructure with minimal changes to the test code and environment


1. This is a pattern based on pub/sub paradigm for testing
2. Decoupling of test scripts and test machines
3. Ability to cause parallel events on multiple test machines
4. Topics representing components of test like MQINSTANCE, BROKERINSTANCE, etc

Existing Technology:

STAF: Software Testing Automation Framework (STAF) is a open source utility that is

popularly used. But didn't help in solving the problem described above as it required knowledge

of the machine that runs the different software. For example, to restart MQ running on a remote system. We had to connect to that system and then perform that action. The test scripts hence required lot of configuration. Also STAF designed more to be a synchronous set of operations and hard to cause mutiple events at the same time.


Page 2 of 4

Components of the solution:

Test script runner: Let's call this the test script publisher (Can even be outside the firewall). It can be connected to the broker and will be publisher and will be run on any one machine of convenience

2. A publish/subscribe engine: Its a very small broker that runs on a central system (can be a Lotus Expeditor micro broker). Can also called as test controller

3. Subscribers running on the test machines: The subscribers that is connected to the broker will be on every test system and depending on software instance on the test system it will subscribe to the broker on a particular topic