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 18:20:26 UTC
svn commit: r982326 [2/2] - in /websites/production/camel/content:
book-cookbook.html book-in-one-page.html cache/main.pageCache
camel-test.html cdi-testing.html
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 17:20:26 2016
@@ -85,7 +85,7 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><p><a shape="rect" class="external-link" href="http://camel.apache.org/testing.html">Testing</a><span style="color: rgb(0,0,0);"> is a crucial part of any development or integration work. In case you're using the Camel CDI integration for your applications, you have a number of options to ease testing.</span></p><p><span style="color: rgb(0,0,0);">You can use CDI for IoC and the Camel testing endpoints like <code><a shape="rect" href="dataset.html">DataSet</a></code>, </span><code><a shape="rect" class="external-link" href="http://camel.apache.org/mock.html">Mock</a></code><span style="color: rgb(0,0,0);">, </span><code><a shape="rect" class="external-link" href="http://camel.apache.org/test.html">Test</a></code> and testing API like <code><a shape="rect" href="advicewith.html">AdviceWith</a></code> and <code><a shape="rect" href="notifybuilder.html">NotifyBuilder</a></code> <span style="color: rgb(0,0,0);">to
create sophisticated integration/unit tests that are easy to run and debug inside your IDE.</span></p><p><span style="color: rgb(0,0,0);">There are a number of supported approaches for testing with CDI in Camel:</span></p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh">Name</th><th colspan="1" rowspan="1" class="confluenceTh">Testing Frameworks Supported</th><th colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-CamelCDITest">Camel CDI Test</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Available as of Camel 2.17</strong></p><p>The Camel CDI test module (<code>camel-test-cdi</code>) provides a JUnit runner that bootstraps a test environment using CDI so that you don't have to be familiar with any CDI testing frameworks
and can concentrate on the testing logic of your Camel CDI applications.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-Arquillian">Arquillian</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li><li>TestNG 5</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="http://arquillian.org/" rel="nofollow">Arquillian</a> is a testing platform that handles all the plumbing of in-container testing with support for a wide range of <a shape="rect" class="external-link" href="http://arquillian.org/modules/" rel="nofollow">target containers</a>. Arquillian can be configured to run your test classes in <em>embedded</em> (in JVM CDI), <em>managed</em> (a real Web server or Java EE application server instance started in a separate process) or <em>remote</em> (the lifecycle of the container isn't managed by Arquillian) modes. You have to create the System Under Test (SU
T) in your test classes using <a shape="rect" class="external-link" href="http://arquillian.org/guides/shrinkwrap_introduction/" rel="nofollow">ShrinkWrap descriptors</a>. The benefit is that you have a very fine-grained control over the application configuration that you want to test. The downside is more code and more complex <em>classpath</em> / class loading structure.</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-PAXExam">PAX Exam</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li><li>TestNG 6</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4" rel="nofollow">PAX Exam</a> lets you test your Camel applications in OSGi, Java EE or standalone CDI containers with the ability to finely configure your <span>System Under Test (SUT),</span> s<span>imilarly to Arquillian. You can use it to test your Camel CDI ap
plications that target OSGi environments like Karaf with <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXCDI/Pax+CDI" rel="nofollow">PAX CDI</a>, but you can use it as well to test your Camel CDI applications in standalone <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/CDI+Containers" rel="nofollow">CDI containers</a>, <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/Web+Containers" rel="nofollow">Web containers</a> and <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/Java+EE+Containers" rel="nofollow">Java EE containers</a>.</span></td></tr></tbody></table></div><h3 id="CDITesting-CamelCDITest">Camel CDI Test</h3><p>With this approach, your test classes use the JUnit runner provided in Camel CDI test. This runner manages the lifecycle of a standalone CDI container and automatically assemble and deploy the System Under Test
(SUT) based on the <em>classpath</em> into the container.</p><p>It deploys the test class as a CDI bean so that dependency injection and any CDI features is available within the test class.</p><p><span style="color: rgb(0,0,0);">Maven users will need to add the following dependency to their </span><code>pom.xml</code><span style="color: rgb(0,0,0);"> for this component:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<div class="wiki-content maincontent"><h2 id="CDITesting-CDITesting">CDI Testing</h2><p><a shape="rect" class="external-link" href="http://camel.apache.org/testing.html">Testing</a><span style="color: rgb(0,0,0);"> is a crucial part of any development or integration work. In case you're using the Camel CDI integration for your applications, you have a number of options to ease testing.</span></p><p><span style="color: rgb(0,0,0);">You can use CDI for IoC and the Camel testing endpoints like <code><a shape="rect" href="dataset.html">DataSet</a></code>, </span><code><a shape="rect" class="external-link" href="http://camel.apache.org/mock.html">Mock</a></code><span style="color: rgb(0,0,0);">, </span><code><a shape="rect" class="external-link" href="http://camel.apache.org/test.html">Test</a></code> and testing API like <code><a shape="rect" href="advicewith.html">AdviceWith</a></code> and <code><a shape="rect" href="notifybuilder.html">NotifyBuilder</a></
code> <span style="color: rgb(0,0,0);">to create sophisticated integration/unit tests that are easy to run and debug inside your IDE.</span></p><p><span style="color: rgb(0,0,0);">There are a number of supported approaches for testing with CDI in Camel:</span></p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh">Name</th><th colspan="1" rowspan="1" class="confluenceTh">Testing Frameworks Supported</th><th colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-CamelCDITest">Camel CDI Test</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Available as of Camel 2.17</strong></p><p>The Camel CDI test module (<code>camel-test-cdi</code>) provides a JUnit runner that bootstraps a test environment using CDI so that you don't have
to be familiar with any CDI testing frameworks and can concentrate on the testing logic of your Camel CDI applications.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-Arquillian">Arquillian</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li><li>TestNG 5</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="http://arquillian.org/" rel="nofollow">Arquillian</a> is a testing platform that handles all the plumbing of in-container testing with support for a wide range of <a shape="rect" class="external-link" href="http://arquillian.org/modules/" rel="nofollow">target containers</a>. Arquillian can be configured to run your test classes in <em>embedded</em> (in JVM CDI), <em>managed</em> (a real Web server or Java EE application server instance started in a separate process) or <em>remote</em> (the lifecycle of the container isn't managed by Arquillian) mode
s. You have to create the System Under Test (SUT) in your test classes using <a shape="rect" class="external-link" href="http://arquillian.org/guides/shrinkwrap_introduction/" rel="nofollow">ShrinkWrap descriptors</a>. The benefit is that you have a very fine-grained control over the application configuration that you want to test. The downside is more code and more complex <em>classpath</em> / class loading structure.</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" href="#CDITesting-PAXExam">PAX Exam</a></td><td colspan="1" rowspan="1" class="confluenceTd"><ul><li>JUnit 4</li><li>TestNG 6</li></ul></td><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4" rel="nofollow">PAX Exam</a> lets you test your Camel applications in OSGi, Java EE or standalone CDI containers with the ability to finely configure your <span>System Under Test (SUT),</span> s<span>imilarly to Arqui
llian. You can use it to test your Camel CDI applications that target OSGi environments like Karaf with <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXCDI/Pax+CDI" rel="nofollow">PAX CDI</a>, but you can use it as well to test your Camel CDI applications in standalone <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/CDI+Containers" rel="nofollow">CDI containers</a>, <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/Web+Containers" rel="nofollow">Web containers</a> and <a shape="rect" class="external-link" href="https://ops4j1.jira.com/wiki/display/PAXEXAM4/Java+EE+Containers" rel="nofollow">Java EE containers</a>.</span></td></tr></tbody></table></div><h3 id="CDITesting-CamelCDITest">Camel CDI Test</h3><p>With this approach, your test classes use the JUnit runner provided in Camel CDI test. This runner manages the lifecycle of a standalone CDI container and automatic
ally assemble and deploy the System Under Test (SUT) based on the <em>classpath</em> into the container.</p><p>It deploys the test class as a CDI bean so that dependency injection and any CDI features is available within the test class.</p><p><span style="color: rgb(0,0,0);">Maven users will need to add the following dependency to their </span><code>pom.xml</code><span style="color: rgb(0,0,0);"> for this component:</span></p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: xml; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-test-cdi</artifactId>
@@ -342,7 +342,8 @@ public class CamelCdiTest {
public void configure() {
from("direct:in").bean("bean").to("direct:out");
}
- }]]></script>
+ }
+}]]></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 {
@@ -400,17 +401,21 @@ 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><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 class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+Â
+ 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;