You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by bu...@apache.org on 2016/03/09 17:18:39 UTC
svn commit: r982321 - in /websites/production/camel/content:
cache/main.pageCache cdi-testing.html
Author: buildbot
Date: Wed Mar 9 16:18:39 2016
New Revision: 982321
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/cdi-testing.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/cdi-testing.html
==============================================================================
--- websites/production/camel/content/cdi-testing.html (original)
+++ websites/production/camel/content/cdi-testing.html Wed Mar 9 16:18:39 2016
@@ -313,22 +313,78 @@ public class PaxCdiOsgiTest {
context.getStatus(), equalTo(ServiceStatus.Started));
}
}
-
]]></script>
-</div></div><p>You can see the tests in<span style="color: rgb(0,0,0);"> the </span><span style="color: rgb(0,0,0);"><code>camel-example-cdi-osgi</code> example for a complete working example of testing a Camel CDI application deployed in an OSGi container using PAX Exam.</span></p><h3 id="CDITesting-TestingPatterns">Testing Patterns</h3><p>You can see the tests in<span style="color: rgb(0,0,0);"> the </span><span style="color: rgb(0,0,0);"><code>camel-example-cdi-test</code> example for a thorough overview of the following testing patterns for Camel CDI applications.</span></p><h4 id="CDITesting-RoutesadvisingwithadviceWith"><span style="color: rgb(0,0,0);">Routes advising with <code>adviceWith</code></span></h4><p><span style="color: rgb(0,0,0);"><span><code><a shape="rect" href="advicewith.html">AdviceWith</a></code> is used for testing Camel routes where you can </span><em>advice</em><span> an existing route before its being tested. It all
ows to add <a shape="rect" class="external-link" href="http://camel.apache.org/intercept.html">Intercept</a> or <em>weave</em> routes for testing purpose, for example using the <a shape="rect" href="mock.html">Mock</a> component</span><span>.</span></span></p><p><span style="color: rgb(0,0,0);">It is recommended to only advice routes which are not started already. To meet that requirement, you can use the </span><code>CamelContextStartingEvent</code> event by declaring an observer method in which you use <code>adviceWith</code> to add a <code>mock</code> endpoint at the end of your Camel route<span style="color: rgb(0,0,0);">, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[void advice(@Observes CamelContextStartingEvent event,
- @Uri("mock:test") MockEndpoint messages,
- ModelCamelContext context) throws Exception {
+</div></div><p>You can see the tests in<span style="color: rgb(0,0,0);"> the </span><span style="color: rgb(0,0,0);"><code>camel-example-cdi-osgi</code> example for a complete working example of testing a Camel CDI application deployed in an OSGi container using PAX Exam.</span></p><h3 id="CDITesting-TestingPatterns">Testing Patterns</h3><p>You can see the tests in<span style="color: rgb(0,0,0);"> the </span><span style="color: rgb(0,0,0);"><code>camel-example-cdi-test</code> example for a thorough overview of the following testing patterns for Camel CDI applications.</span></p><h4 id="CDITesting-Testroutes"><span style="color: rgb(0,0,0);">Test routes</span></h4><p><span style="color: rgb(0,0,0);">You may want to add some Camel routes to your Camel CDI applications for testing purpose. For example to route some exchanges to a <code>MockEndpoint</code> instance. You can do that by declaring a <code>RouteBuilder</code> bean within the test class as you w
ould normally do in your application code, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+Â
+ // Declare a RouteBuilder bean for testing purpose
+ // that is automatically added to the Camel context
+ static class TestRoute extends RouteBuilder {
- context.getRouteDefinition("route")
- .adviceWith(context, new AdviceWithRouteBuilder() {
- @Override
- public void configure() {
- weaveAddLast().to("mock:test");
- }
- });
+ @Override
+ public void configure() {
+ from("direct:out").routeId("test").to("mock:out");
+ }
+Â
+ // And retrieve the MockEndpoint for further assertions
+ @Inject
+ @Uri("mock:out")
+ MockEndpoint mock;
}]]></script>
-</div></div><h4 id="CDITesting-Beanalternatives"><span style="color: rgb(0,0,0);">Bean alternatives</span></h4><p><span style="color: rgb(0,0,0);"><br clear="none"></span></p><h4 id="CDITesting-Testroutes"><span style="color: rgb(0,0,0);">Test routes</span></h4><p><span style="color: rgb(0,0,0);"><br clear="none"></span></p><h4 id="CDITesting-Camelcontextcustomisation"><span style="color: rgb(0,0,0);">Camel context customisation</span></h4><p><span style="color: rgb(0,0,0);">You may need to customise your Camel contexts for testing purpose, for example disabling JMX management to avoid TCP port allocation conflict. You can do that by declaring a custom Camel context bean in your test class, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">You can find more information in <a shape="rect" href="cdi.html#CDI-Auto-detectingCamelroutes">auto-detecting Camel routes</a>.</span></p><h4 id="CDITesting-Beanalternatives"><span style="color: rgb(0,0,0);">Bean alternatives</span></h4><p><span style="color: rgb(0,0,0);">You may want to replace a bean that is used in your Camel routes by another bean for testing purpose, for example to mock it or change the behaviour of the application bean.</span></p><p><span style="color: rgb(0,0,0);">Imagine you have the following route in your application:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[public class Application {
+
+ @ContextName("camel-test-cdi")
+ static class Hello extends RouteBuilder {
+
+ @Override
+ public void configure() {
+ from("direct:in").bean("bean").to("direct:out");
+ }
+ }]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">And the corresponding bean:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@Named("bean")
+public class Bean {
+
+ public String process(@Body String body) {
+ return body;
+ }
+}]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">Then you can replace the bean above in your tests by declaring an <em>alternative</em> bean, annotated with <code>@Alternative</code>, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@Alternative
+@Named("bean")
+public class AlternativeBean {
+
+ public String process(@Body String body) {
+ return body + " with alternative bean!";
+ }
+}]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">And you need to activate (a.k.a. <em>select</em> in CDI terminology) this alternative bean in your tests. If your using the <code>CamelCdiRunner</code> JUnit runner, you can do that with the <code>@Beans</code> annotation provided by the Camel CDI test module, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+@Beans(alternatives = AlternativeBean.class)
+public class CamelCdiTest {
+
+ @Test
+ public void testAlternativeBean(@Uri("direct:in") ProducerTemplate producer
+ @Uri("mock:out") MockEndpoint mock) throws InterruptedException {
+ mock.expectedMessageCount(1);
+ mock.expectedBodiesReceived("test with alternative bean!");
+
+ producer.sendBody("test");
+
+ MockEndpoint.assertIsSatisfied(1L, TimeUnit.SECONDS, mock);
+ }
+
+ static class TestRoute extends RouteBuilder {
+
+ @Override
+ public void configure() {
+ from("direct:out").routeId("test").to("mock:out");
+ }
+ }
+}]]></script>
+</div></div><h4 id="CDITesting-Camelcontextcustomisation"><span style="color: rgb(0,0,0);">Camel context customisation</span></h4><p><span style="color: rgb(0,0,0);">You may need to customise your Camel contexts for testing purpose, for example disabling JMX management to avoid TCP port allocation conflict. You can do that by declaring a custom Camel context bean in your test class, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
Â
@@ -343,7 +399,20 @@ public class CamelCdiTest {
}
}
}]]></script>
-</div></div><p><span style="color: rgb(0,0,0);">In that example, the custom Camel context bean declared in the test class will be used during the test execution instead of the default Camel context bean provided by the <a shape="rect" href="cdi.html">Camel CDI component</a>.</span></p><p><span style="color: rgb(0,0,0);font-weight: bold;">JUnit rules</span></p><p><span style="color: rgb(0,0,0);">Camel CDI test starts the CDI container after all the JUnit class rules have executed.</span></p><p><span style="color: rgb(0,0,0);">That way, you can use JUnit class rules to initialise (resp. clean-up) resources that your test classes would require during their execution before the container initialises (resp. after the container has shutdown). For example, you could use an embedded JMS broker like <span style="color: rgb(0,0,0);"><a shape="rect" class="external-link" href="https://activemq.apache.org/artemis/">ActiveMQ Artemis</a> to test your Camel JMS application</span>, e.g.:</span></p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">In that example, the custom Camel context bean declared in the test class will be used during the test execution instead of the default Camel context bean provided by the <a shape="rect" href="cdi.html">Camel CDI component</a>.</span></p><h4 id="CDITesting-RoutesadvisingwithadviceWith"><span style="color: rgb(0,0,0);">Routes advising with <code>adviceWith</code></span></h4><p><span style="color: rgb(0,0,0);"><span><code><a shape="rect" href="advicewith.html">AdviceWith</a></code> is used for testing Camel routes where you can </span><em>advice</em><span> an existing route before its being tested. It allows to add <a shape="rect" class="external-link" href="http://camel.apache.org/intercept.html">Intercept</a> or <em>weave</em> routes for testing purpose, for example using the <a shape="rect" href="mock.html">Mock</a> component</span><span>.</span></span></p><p><span style="color: rgb(0,0,0);">It is re
commended to only advice routes which are not started already. To meet that requirement, you can use the </span><code>CamelContextStartingEvent</code> event by declaring an observer method in which you use <code>adviceWith</code> to add a <code>mock</code> endpoint at the end of your Camel route<span style="color: rgb(0,0,0);">, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[void advice(@Observes CamelContextStartingEvent event,
+ @Uri("mock:test") MockEndpoint messages,
+ ModelCamelContext context) throws Exception {
+
+ context.getRouteDefinition("route")
+ .adviceWith(context, new AdviceWithRouteBuilder() {
+ @Override
+ public void configure() {
+ weaveAddLast().to("mock:test");
+ }
+ });
+}]]></script>
+</div></div><h4 id="CDITesting-JUnitrules"><span style="color: rgb(0,0,0);">JUnit rules</span></h4><p><span style="color: rgb(0,0,0);">Camel CDI test starts the CDI container after all the JUnit class rules have executed.</span></p><p><span style="color: rgb(0,0,0);">That way, you can use JUnit class rules to initialise (resp. clean-up) resources that your test classes would require during their execution before the container initialises (resp. after the container has shutdown). For example, you could use an embedded JMS broker like <span><a shape="rect" class="external-link" href="https://activemq.apache.org/artemis/">ActiveMQ Artemis</a> to test your Camel JMS application</span>, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[import org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS;
Â
@RunWith(CamelCdiRunner.class)
@@ -373,7 +442,7 @@ public class CamelCdiTest {
producer.sendBody("message");
}
}]]></script>
-</div></div><p><span style="color: rgb(0,0,0);">Another use case is to assert the behaviour of your application after it has shutdown. In that case, you can use the <code>Verifier</code> rule, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">Another use case is to assert the behaviour of your application after it has shutdown. In that case, you can use the <code>Verifier</code> rule, e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[import org.junit.rules.Verifier;
Â
@RunWith(CamelCdiRunner.class)