Author: karlkilden
Date: Mon Feb 10 12:18:20 2014
New Revision: 1566592
URL: http://svn.apache.org/r1566592
Log:
Further improved test documentation.
Modified:
openwebbeans/cms-site/trunk/content/testing_general.mdtext
Modified: openwebbeans/cms-site/trunk/content/testing_general.mdtext
URL:
http://svn.apache.org/viewvc/openwebbeans/cms-site/trunk/content/testing_general.mdtext?rev=1566592&r1=1566591&r2=1566592&view=diff
==============================================================================
--- openwebbeans/cms-site/trunk/content/testing_general.mdtext (original)
+++ openwebbeans/cms-site/trunk/content/testing_general.mdtext Mon Feb 10
12:18:20 2014
@@ -1,50 +1,74 @@
-Title: OpenWebBeans CdiCtrl
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-# Testing strategies for projects that leverage CDI
-
-One could argue that unit tests are harder to write when your instances are
managed by a container.
-However this is only true if the booting of said container is uncharted
territory.
-But lets assume the container control is taken cared of handily. Well then it
can be quite the breath of fresh air to test code
-that leverage dependency injection.
-
-Here comes the good news. Testing OpenWebBeans and CDI in general (and
actually many other Java EE frameworks)
-is in a good state as of today and testing frameworks are reaching a pretty
decent level of maturity. Stay with us and
-we will compare the pros and cons with
-the different strategies.
-
-
-
-
-### Good Practice
-
-We won't go in to detail on how to properly use unit tests or integration
tests in your project. However so called "Whitebox Testing" is
-discouraged. Using whitebox testing is often critizied regardless but with
frameworks that leverage
-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.
-
-
-### Start small with normal unit tests
-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 ``@PostConstruct``) then go ahead and
upgrade the test to CDI aware.
-
-### CDI aware options
-The by far easiest and most straight forward way to write your first test is
defientetly with
\ No newline at end of file
+Title: Testing strategies
+Notice: Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ .
+ http://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+# Testing strategies for projects that leverage CDI
+
+One could argue that unit tests are harder to write when your instances are
managed by a container.
+However this is only true if the booting of said container is uncharted
territory.
+But lets assume the container control is taken cared of handily. Well then it
can be quite the breath of fresh air to test code
+that leverage dependency injection.
+
+Here comes the good news. Testing OpenWebBeans and CDI in general (and
actually many other Java EE frameworks)
+is in a good state as of today and testing frameworks are reaching a pretty
decent level of maturity. Stay with us and
+we will compare the pros and cons with
+the different strategies.
+
+### Good Practice
+
+We won't go in to detail on how to properly use unit tests or integration
tests in your project. However so called "Whitebox Testing" is
+discouraged. Using whitebox testing is often critizied regardless but with
frameworks that leverage
+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.
+
+
+### Start small with plain tests
+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 ``@PostConstruct``) then go ahead and
upgrade the test to CDI aware. To get started with plain unit testing please
+refer to [JUnit][1] or [TestNG][2] as a starting point.
+
+### CDI aware tests
+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 ``CdiCtrl`` can support any CDI environment including tests. Apache
Deltaspike Core may also prove useful (perhaps especially the BeanProvider).
[Deltaspike Core][3].
+
+**[Apache Deltaspike Test-Control](testing_test-control.html)**<br>
+The by far easiest and most straight forward way to write your first test is
definitely with [Apache Deltaspike Test-Control][4].
+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 ``CdiCtrl`` it's advised to
continue reading below for more information.
+
+**[Apache Deltaspike CdiCtrl](testing_test-control.html)**<br>
+Since ``Test-Control`` 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 ``Apache
Deltaspike CdiCtrl`` directly but communicating with them might be a
+ good idea, please refer to [Deltaspike Community][5] for contact details.
``CdiCtrl``
+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.
``CdiCtrl`` is commonly referred to as the lightweight champion of CDI testing.
+In it's nature it's simple and to the point (``Test-Control`` even more so).
+
+**[JBoss Arquillian](testing_arquillian.html)**<br>
+Crowned the heavyweight champion of CDI testing certainly not all for naught.
``Arquillian`` 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.
+
+ [1]: http://junit.org/
+ [2]: http://testng.org/doc/index.html
+ [3]: http://deltaspike.apache.org/core.html
+ [4]: deltaspike.apache.org/test-control.html
+ [5]: http://deltaspike.apache.org/community.html
\ No newline at end of file
