svn commit: r897146 - in /websites/staging/openwebbeans/trunk/content: ./ testing_general.html

[bu...@apache.org]

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>