JCAPS Unit Testing - Part 2
Last time I explained how to trigger a JCAPS JCD from a web browser. This entry will hopefully clarify some of the items in that post, before building on that functionality to execute JUnit tests using HTTPUnit.
First, the JCD created to listen for HTTP requests (let's call it jcdUnitTester) will drop messages on a queue or topic where the JCD we want to test is listening (call it the jcdTarget). The jcdTarget normally processes the incoming message, then passes the result to the next process via a queue, topic, or some other transport mechanism (call it targetResponse). For jcdUnitTester to return the message to browser in the HTTP response, jcdUnitTester must be listening on targetResponse (creating a loop between jcdUnitTester and jcdTarget.)
In my code, most of my jcdTargets involved JCDs sending responses back on a topic or queue. To make the JMS jcdTargets dynamic, I've taken advantage of the JMS eGate class's sendTo method. The targetResponse is obtained from the class's getMessageProperties().getReplyTo() method. To set this value, jcdUnitTester and other classes sending messages to jcdTarget use getMessageProperties().setReplyTo(). This convention is what makes it possible for jcdUnitTester to test individual jcdTargets in an otherwise tightly integrated environment.
*****
One other hint, by default JCAPS will not place messages on the queue for consumption until the JCD exits. This will not work for jcdUnitTester since it needs to send the message to trigger the jcdTarget then wait for the response. To overcome this, I've set the JMS queue/topic properties to "Transacted" and "Nonpersistent" instead of "XA" and "Persistent". I'm sure there are other ways and settings that will achieve the same result, but these have worked for me.
First, the JCD created to listen for HTTP requests (let's call it jcdUnitTester) will drop messages on a queue or topic where the JCD we want to test is listening (call it the jcdTarget). The jcdTarget normally processes the incoming message, then passes the result to the next process via a queue, topic, or some other transport mechanism (call it targetResponse). For jcdUnitTester to return the message to browser in the HTTP response, jcdUnitTester must be listening on targetResponse (creating a loop between jcdUnitTester and jcdTarget.)
In my code, most of my jcdTargets involved JCDs sending responses back on a topic or queue. To make the JMS jcdTargets dynamic, I've taken advantage of the JMS eGate class's sendTo method. The targetResponse is obtained from the class's getMessageProperties().getReplyTo() method. To set this value, jcdUnitTester and other classes sending messages to jcdTarget use getMessageProperties().setReplyTo(). This convention is what makes it possible for jcdUnitTester to test individual jcdTargets in an otherwise tightly integrated environment.
*****
One other hint, by default JCAPS will not place messages on the queue for consumption until the JCD exits. This will not work for jcdUnitTester since it needs to send the message to trigger the jcdTarget then wait for the response. To overcome this, I've set the JMS queue/topic properties to "Transacted" and "Nonpersistent" instead of "XA" and "Persistent". I'm sure there are other ways and settings that will achieve the same result, but these have worked for me.
Comments