Stubs: Overview and tasks

Stubs can be used to simulate services that you are unable to use or that are otherwise unavailable.

For example, if you are testing a TIBCO BusinessWorks process but you do not always have access to TIBCO Designer, you can record the process events and create a stub from them. You can then run the stub in place of Designer. For more information, see HCL OneTest Virtualization.

Stubs are message consumers. Because messages are delivered in a round-robin fashion, a stub will not receive all of the messages if other consumer applications are connected to the message queue. However, the message delivery mechanism is defined by the queue configuration. Therefore, by altering the queue property, you can ensure that the stub receives all the messages. By configuring a queue as Exclusive, the consumer that subscribes first to the message queue gets all of the messages. This queue configuration can be used to make sure that a stub receives all of the messages, even if there are other consumer applications connected to the message queue at a later time. An administrator can use the TIBCO tool tibemsadmin to set the Exclusive property for a queue by using the addprop queue or setprop queue command. To receive all of the messages from the queue, the stub must subscribe to the message queue before other message consumers.

A stub can be simple (for example, to simulate a single service that uses a single message case and the default case) or complex (for example, to simulate a Web Service or some other point-to-point operation that includes multiple message types or operations). In either case, the basic principles are the same, that is, a specific reply is sent when a specific message type is received.

At the most basic level, a stub receives a message and (optionally) validates its contents. Based on the validation results, or on the fact that the message was received, the stub can return some static response, such as a simple log action or a reply message.

A more complex stub can receive incoming messages and, based on the specific contents of those messages, carry out a more extensive set of test activities such as the following actions:
  • Looking up data in a database or spreadsheet
  • Updating one or more records in a database
  • Using failure paths
By using message cases and other test actions, a stub can be configured to generate responses in an intelligent manner.

For more information, including detailed task topics, see Creating message-based stubs and Creating and modifying database stubs.

Feedback