For example, imagine a route which is doing some work and sending the message 
to jms:queue:...
More than that, it's packaged as an OSGi bundle which is only accepting some 
external configuration from Configuration Admin. And you need to write an 
integration test.
Then you would need a JMS broker. But stub endpoint allows you to run an 
integration test without it.
Something like:
to((destStubEnabled ? "stub:" : "") + "jms:queue:" + jmsQueue + 
Also you can stub your input as well, using some other boolean switch in the 

And in the test, you can reference the bundle's CamelContext inside the 
container (karaf), and send/receive messages to/from stub endpoints.

We are using a following model:
1. Unit tests are written to verify the business logic (POJOs)
2. Integration tests are written to verify the combination of business logic + 
transport logic (Camel) inside the container Karaf, but without having anything 
outside the container
3. Acceptance tests are written to verify the same, but with real components 
outside of the container

Best regards,
Konstantin Chernov.

-----Original Message-----
From: Jeremy Ross <jeremy.g.r...@gmail.com> 
Sent: Tuesday, January 14, 2020 10:55 AM
To: users@camel.apache.org
Subject: Stub component usage patterns

Hi all,

I'm not sure I understand how the Stub component is intended to be used.
The canonical example seems to be a JMS consumer in production. Camel in Action 
says "stub any Camel endpoint by prefixing the endpoint with stub:".
Cool, well if I'm testing production routes, I don't want to modify them, so 
would it make sense to use replaceFromWith() to replace the JMS consumer with a 
stub? How would this be better than just replacing the JMS consumer with a 
direct or vm? Does stub offer some other benefit?

Thanks for any ideas or suggestions.


Reply via email to