camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject 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
Date Wed, 09 Mar 2016 17:20:26 GMT
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);">&#160;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>,&#160;</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);">,&#160;</span><code><a shape="rect" class="external-link"
href="http://camel.apache.org/test.html">Test</a></code>&#160;and testing
API like&#160;<code><a shape="rect" href="advicewith.html">AdviceWith</a></code>
and&#160;<code><a shape="rect" href="notifybuilder.html">NotifyBuilder</a></code>&#160;<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&#160;</span><code>pom.xml</code><span
style="color: rgb(0,0,0);">&#160;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);">&#160;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>,&#160;</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);">,&#160;</span><code><a shape="rect" class="external-link"
href="http://camel.apache.org/test.html">Test</a></code>&#160;and testing
API like&#160;<code><a shape="rect" href="advicewith.html">AdviceWith</a></code>
and&#160;<code><a shape="rect" href="notifybuilder.html">NotifyBuilder</a></
 code>&#160;<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&#160;</span><code>pom.xml</code><span
style="color: rgb(0,0,0);">&#160;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[&lt;dependency&gt;
     &lt;groupId&gt;org.apache.camel&lt;/groupId&gt;
     &lt;artifactId&gt;camel-test-cdi&lt;/artifactId&gt;
@@ -342,7 +342,8 @@ public class CamelCdiTest {
         public void configure() {
             from(&quot;direct:in&quot;).bean(&quot;bean&quot;).to(&quot;direct:out&quot;);
         }
-    }]]></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(&quot;bean&quot;)
 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&#160;<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&#160;</span><em>advice</em><span>&#160;an
existing route before its being tested. It allows to add&#160;<a shape="rect" class="external-link"
href="http://camel.apache.org/intercept.html">Intercept</a>&#160;or <em>weave</em>
routes for testing purpose, for example using the&#160;<a shape="rect" href="mock.html">Mock</a>&#160;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&#160;</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(&quot;mock:test&quot;) MockEndpoint messages,
-            ModelCamelContext context) throws Exception {
-
-    context.getRouteDefinition(&quot;route&quot;)
-        .adviceWith(context, new AdviceWithRouteBuilder() {
-            @Override
-            public void configure() {
-                weaveAddLast().to(&quot;mock:test&quot;);
-            }
-        });
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+ 
+    void advice(@Observes CamelContextStartingEvent event,
+                @Uri(&quot;mock:test&quot;) MockEndpoint messages,
+                ModelCamelContext context) throws Exception {
+
+        context.getRouteDefinition(&quot;route&quot;)
+            .adviceWith(context, new AdviceWithRouteBuilder() {
+                @Override
+                public void configure() {
+                    weaveAddLast().to(&quot;mock:test&quot;);
+                }
+            });
+    }
 }]]></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&#160;<span><a shape="rect" class="external-link"
href="https://activemq.apache.org/artemis/">ActiveMQ Artemis</a>&#160;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;



Mime
View raw message