Purging JMS destinations
Purging JMS destinations during the test run is quite essential. Different test cases can influence each other when sending messages to the same JMS destinations. A test case should only receive those messages that actually belong to it. Therefore it is a good idea to purge all JMS queue destinations between the test cases. Obsolete messages that are stuck in a JMS queue for some reason are then removed so that the following test case is not offended.
Note Citrus provides special support for JMS related features. We have to activate those JMS features in our test case by adding a special "jms" namespace and schema definition location to the test case XML.
<spring:beans xmlns="http://www.citrusframework.org/schema/testcase"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jms="http://www.citrusframework.org/schema/jms/testcase"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.citrusframework.org/schema/testcase
http://www.citrusframework.org/schema/testcase/citrus-testcase.xsd
http://www.citrusframework.org/schema/jms/testcase
http://www.citrusframework.org/schema/jms/testcase/citrus-jms-testcase.xsd">
[...]
</beans>
Now we are ready to use the JMS features in our test case in order to purge some JMS queues. This can be done with following action definition:
XML DSL
<testcase name="purgeTest">
<actions>
<jms:purge-jms-queues>
<jms:queue name="Some.JMS.QUEUE.Name"/>
<jms:queue name="Another.JMS.QUEUE.Name"/>
<jms:queue name="My.JMS.QUEUE.Name"/>
</jms:purge-jms-queues>
<jms:purge-jms-queues connection-factory="connectionFactory">
<jms:queue name="Some.JMS.QUEUE.Name"/>
<jms:queue name="Another.JMS.QUEUE.Name"/>
<jms:queue name="My.JMS.QUEUE.Name"/>
</jms:purge-jms-queues>
</actions>
</testcase>
Notice that we have referenced the jms namespace when using the purge-jms-queues test action.
Java DSL designer
@Autowired
@Qualifier("connectionFactory")
private ConnectionFactory connectionFactory;
@CitrusTest
public void purgeTest() {
purgeQueues()
.queue("Some.JMS.QUEUE.Name")
.queue("Another.JMS.QUEUE.Name");
purgeQueues(connectionFactory)
.timeout(150L) // custom timeout in ms
.queue("Some.JMS.QUEUE.Name")
.queue("Another.JMS.QUEUE.Name");
}
Java DSL runner
@Autowired
@Qualifier("connectionFactory")
private ConnectionFactory connectionFactory;
@CitrusTest
public void purgeTest() {
purgeQueues(action ->
action.queue("Some.JMS.QUEUE.Name")
.queue("Another.JMS.QUEUE.Name"));
purgeQueues(action -> action.connectionFactory(connectionFactory)
.timeout(150L) // custom timeout in ms
.queue("Some.JMS.QUEUE.Name")
.queue("Another.JMS.QUEUE.Name"));
}
Purging the JMS queues in every test case is quite exhausting because every test case needs to define a purging action at the very beginning of the test. Fortunately the test suite definition offers tasks to run before, between and after the test cases which should ease up this tasks a lot. The test suite offers a very simple way to purge the destinations between the tests. See testsuite-before-testfor more information about this.
As you can see in the next example it is quite easy to specify a group of destinations in the Spring configuration that get purged before a test is executed.
<citrus:before-test id="purgeBeforeTest">
<citrus:actions>
<jms:purge-jms-queues>
<jms:queue name="Some.JMS.QUEUE.Name"/>
<jms:queue name="Another.JMS.QUEUE.Name"/>
</jms:purge-jms-queues>
</citrus:actions>
</citrus:before-test>
Note Please keep in mind that the JMS related configuration components in Citrus belong to a separate XML namespace jms: . We have to add this namespace declaration to each test case XML and Spring bean XML configuration file as described at the very beginning of this section.
The syntax for purging the destinations is the same as we used it inside the test case. So now we are able to purge JMS destinations with given destination names. But sometimes we do not want to rely on queue or topic names as we retrieve destinations over JNDI for instance. We can deal with destinations coming from JNDI lookup like follows:
<jee:jndi-lookup id="jmsQueueHelloRequestIn" jndi-name="jms/jmsQueueHelloRequestIn"/>
<jee:jndi-lookup id="jmsQueueHelloResponseOut" jndi-name="jms/jmsQueueHelloResponseOut"/>
<citrus:before-test id="purgeBeforeTest">
<citrus:actions>
<jms:purge-jms-queues>
<jms:queue ref="jmsQueueHelloRequestIn"/>
<jms:queue ref="jmsQueueHelloResponseOut"/>
</jms:purge-jms-queues>
</citrus:actions>
</citrus:before-test>
We just use the attribute 'ref' instead of 'name' and Citrus is looking for a bean reference for that identifier that resolves to a JMS destination. You can use the JNDI bean references inside a test case, too.
XML DSL
<testcase name="purgeTest">
<actions>
<jms:purge-jms-queues>
<jms:queue ref="jmsQueueHelloRequestIn"/>
<jms:queue ref="jmsQueueHelloResponseOut"/>
</jms:purge-jms-queues>
</actions>
</testcase>
Of course you can use queue object references also in Java DSL test cases. Here we easily can use Spring's dependency injection with autowiring to get the object references from the IoC container.
Java DSL designer
@Autowired
@Qualifier("jmsQueueHelloRequestIn")
private Queue jmsQueueHelloRequestIn;
@Autowired
@Qualifier("jmsQueueHelloResponseOut")
private Queue jmsQueueHelloResponseOut;
@CitrusTest
public void purgeTest() {
purgeQueues()
.queue(jmsQueueHelloRequestIn)
.queue(jmsQueueHelloResponseOut);
}
Java DSL runner
@Autowired
@Qualifier("jmsQueueHelloRequestIn")
private Queue jmsQueueHelloRequestIn;
@Autowired
@Qualifier("jmsQueueHelloResponseOut")
private Queue jmsQueueHelloResponseOut;
@CitrusTest
public void purgeTest() {
purgeQueues(action ->
action.queue(jmsQueueHelloRequestIn)
.queue(jmsQueueHelloResponseOut));
}
Note You can mix queue name and queue object references as you like within one single purge queue test action.