Author: buildbot
Date: Mon Feb 10 12:18:25 2014
New Revision: 897146
Log:
Staging update by buildbot for openwebbeans
Modified:
websites/staging/openwebbeans/trunk/content/ (props changed)
websites/staging/openwebbeans/trunk/content/testing_general.html
Propchange: websites/staging/openwebbeans/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Feb 10 12:18:25 2014
@@ -1 +1 @@
-1566552
+1566592
Modified: websites/staging/openwebbeans/trunk/content/testing_general.html
==============================================================================
--- websites/staging/openwebbeans/trunk/content/testing_general.html (original)
+++ websites/staging/openwebbeans/trunk/content/testing_general.html Mon Feb 10
12:18:25 2014
@@ -89,13 +89,31 @@ discouraged. Using whitebox testing is o
proxies it's simply not something you should attempt. Any reflection trick
will would likely miss the mark and modify the proxy.
Instead focus on functional tests and structure your code with high cohesion
so that testing the public methods get's the job done.
Remember to add beans.xml and other resources to your to your test path.</p>
-<h3 id="start-small-with-normal-unit-tests">Start small with normal unit
tests</h3>
+<h3 id="start-small-with-plain-tests">Start small with plain tests</h3>
<p>Testing code that leverage CDI does not differ much from using CDI in your
project. You should start with just a plain pojo
in your project and likewise a plain unit test. Only when you need context
should you upgrade the pojo to a CDI managed instance.
Still this does not mean you automatically need something more then plain unit
test. But when you need the container to act on your
-instances (for example to trigger <code>@PostConstruct</code>) then go ahead
and upgrade the test to CDI aware.</p>
-<h3 id="cdi-aware-options">CDI aware options</h3>
-<p>The by far easiest and most straight forward way to write your first test
is defientetly with </p>
+instances (for example to trigger <code>@PostConstruct</code>) then go ahead
and upgrade the test to CDI aware. To get started with plain unit testing please
+refer to <a href="http://junit.org/";>JUnit</a> or <a
href="http://testng.org/doc/index.html";>TestNG</a> as a starting point.</p>
+<h3 id="cdi-aware-tests">CDI aware tests</h3>
+<p>These frameworks for testing all rely on either JUnit or TestNG and simply
adds CDI container control capabilities. None of these frameworks are exclusive
+and <code>CdiCtrl</code> can support any CDI environment including tests.
Apache Deltaspike Core may also prove useful (perhaps especially the
BeanProvider). <a href="http://deltaspike.apache.org/core.html";>Deltaspike
Core</a>.</p>
+<p><strong><a href="testing_test-control.html">Apache Deltaspike
Test-Control</a></strong><br>
+The by far easiest and most straight forward way to write your first test is
definitely with <a href="deltaspike.apache.org/test-control.html">Apache
Deltaspike Test-Control</a>.
+This way of testing boots the CDI Container with minimal code and there's not
much to learn besides CDI and unit testing with JUnit / TestNG.
+Since Test-Control is a thin layer on top of <code>CdiCtrl</code> it's advised
to continue reading below for more information.</p>
+<p><strong><a href="testing_test-control.html">Apache Deltaspike
CdiCtrl</a></strong><br>
+Since <code>Test-Control</code> is very new it currently lacks support for
TestNG and only offers one integration point (MyFaces-Test). If you experience
Test-Control
+as insufficient the Apache Deltaspike team might propose that you use
<code>Apache Deltaspike CdiCtrl</code> directly but communicating with them
might be a
+ good idea, please refer to <a
href="http://deltaspike.apache.org/community.html";>Deltaspike Community</a> for
contact details. <code>CdiCtrl</code>
+is a powerful framework that Test-Control is built on top off and using it
directly is another solution to consider.
+This is still common and well documented since Test-Control is a new module.
<code>CdiCtrl</code> is commonly referred to as the lightweight champion of CDI
testing.
+In it's nature it's simple and to the point (<code>Test-Control</code> even
more so). </p>
+<p><strong><a href="testing_arquillian.html">JBoss Arquillian</a></strong><br>
+Crowned the heavyweight champion of CDI testing certainly not all for naught.
<code>Arquillian</code> offers fine grained control over the deployment and has
+many popular extensions for testing. For example testing with a web based user
interface is possible. If you want to test very complex combinations in your
deployments
+or you need to isolate to the bare minimum, then Arquillian really shines. It
also offers several xml configuration points and similar that might be needed
for large
+complicated projects.</p>
</div>
<hr>
