Hi. 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 + "?connectionFactory=#jms") Also you can stub your input as well, using some other boolean switch in the configuration.
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. Jeremy
