Unit test freindly activemqcomponent

[murray.hughes]

I've got routes using amq useing blueprint.  What's the best strategy for unit testing?

I tried to use CF from ActiveMQ service running in container.

Blueprint excerpt:

And this does allow my unit tests to run, by mocking the endpoints with advice.

but its not the most efficient at run time.  this is my current solution. 

I tried Emedded activeMQ broker in a unit test (CamelBlueprintTestSupport):

     @Override

     protected CamelContext createCamelContext() throws Exception {

          CamelContext camelContext = super.createCamelContext();

          //embedded broker:

          brokerService = BrokerFactory.createBroker("broker:(vm://localhost)?persistent=false");

          brokerService.start();

          amqComponent = camelContext.getComponent("activemq", ActiveMQComponent.class);

          amqComponent.setBrokerURL("vm:localhost?waitForStart=20000$create=false");

          return camelContext;

     }

I'm attracted to this option because I could include activemq in the test senarios.

But I'm unsure how to wire it up.

Ideally I'd like the connectionFactory reference used when the blueprint starts in the Fuse ESB, and the enbedded broker used in the CamelBlueprintTestSupport.  How to do this?

Edited by: murray.hughes on Jul 18, 2012 11:58 PM

[njiang]

If you just want to test route as a unit test, you can use seda component to replace the activemq component by define the jms component like this.

<bean id="jms" class="org.apache.camel.component.seda.SedaComponent">

And you can include this file for testing, it could be much easier for you not to touch the broker configuration staff.

Willem

[murray.hughes]

That is a clever trick.  Thanks.  I can now relibably run the unit tests.

I just realised that in order to take advantage of this I needed a separate blueprint file for the jms beans, so I could use a different one in unit test.

I ended up with the following files:

src\main\resources\OSGI-INF\blueprint\jms.xml:

File src\test\java\com\x\RouteTest.java

public class RouteTest extends CamelBlueprintTestSupport {

     @Override

    protected String getBlueprintDescriptor() {

        return "/OSGI-INF/blueprint/jms-test.xml,/OSGI-INF/blueprint/blueprint.xml";

    }

[davsclaus]

I would assume you could have a 2nd blueprint XML file where you setup ActiveMQ, which you then refer from the 1st blueprint XML file, just as you do now with the "seda" trick.

Btw for Camel 2.10 onwards we have a "stub" component instead of seda, its just like seda, but dont validate uri parameters, so you can more easily stub out endpoints that have parameters, that the seda component would otherwise fail to use.

[murray.hughes]

I should clarify my current method of using mutiple blueprint files, as I didn't make it very clear above, and it seems to work:

Production:

src\main\resources\OSGI-INF\blueprint\jms.xml:  (in-container activemq as above)src\main\resources\OSGI-INF\blueprint\blueprint.xml:  (includes the camel route)

I understand the reason the above two files get utilised when deployed in the container is because they are found in the OSGI-INF\blueprint directory.

Test:

src\test\resources\OSGI-INF\blueprint\jms-test.xml (seda jms as described above)

src\main\resources\OSGI-INF\blueprint\blueprint.xml (includes the camel route)

Note the mix of main & test directories. 

I understand there two files get utilised at unit test time because they are in the maven unit test classpath and referred to in the following part of the unit test:

@Override

protected String getBlueprintDescriptor() {

return "/OSGI-INF/blueprint/jms-test.xml,/OSGI-INF/blueprint/blueprint.xml";

}

Please let me know if my understanding of why this works is incorrect.

The above does not rely on one blueprint file referring to another.

Is there a way to refer to one blueprint file from another?

Thanks for the tip about camel 2.10.  I see there are a number of camel 2.10 features that enhance unit testing. I'm unsure of the process to upgrade FuseESB to camel 2.10 to take advantage of them, so have avoided that.