openwebbeans-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r897146 - in /websites/staging/openwebbeans/trunk/content: ./ testing_general.html
Date Mon, 10 Feb 2014 12:18:25 GMT
Author: buildbot
Date: Mon Feb 10 12:18:25 2014
New Revision: 897146

Staging update by buildbot for openwebbeans

    websites/staging/openwebbeans/trunk/content/   (props changed)

Propchange: websites/staging/openwebbeans/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Mon Feb 10 12:18:25 2014
@@ -1 +1 @@

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="">JUnit</a> or <a href="">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="">Deltaspike
+<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="">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="">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>

View raw message