Author: karlkilden
Date: Sun Feb 9 20:35:21 2014
New Revision: 1566395
URL: http://svn.apache.org/r1566395
Log:
First draft for these three pages regarding testing documentation.
Modified:
openwebbeans/cms-site/trunk/content/testing_arquillian.mdtext
openwebbeans/cms-site/trunk/content/testing_general.mdtext
openwebbeans/cms-site/trunk/content/testing_test-control.mdtext
Modified: openwebbeans/cms-site/trunk/content/testing_arquillian.mdtext
URL:
http://svn.apache.org/viewvc/openwebbeans/cms-site/trunk/content/testing_arquillian.mdtext?rev=1566395&r1=1566394&r2=1566395&view=diff
==============================================================================
--- openwebbeans/cms-site/trunk/content/testing_arquillian.mdtext (original)
+++ openwebbeans/cms-site/trunk/content/testing_arquillian.mdtext Sun Feb 9
20:35:21 2014
@@ -16,224 +16,43 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-# Testing your application with Apache DeltaSpike CdiCtrl
+# Testing your application with JBoss Arquillian
+## About Arquillian
-## About CdiCtrl
-
-``CdiCtrl`` is *not* part of Apache OpenWebBeans but a module of
-[Apache DeltaSpike][1].
-
-The ``CdiCtrl`` interface abstracts away all the logic to boot a CDI Container
-and controls the lifecycle of it's Contexts (Request Context, Session Context,
etc).
-
-The actual CDI Container is determined by using the
``java.util.ServiceLoader``.
-There are a few different implementations available. Besides Apache
OpenWebBeans
-there are also plugins for JBoss Weld and [Apache TomEE][2].
-
-## Adding OpenWebBeans CdiCtrl to your project
-
-The following are the dependencies you need in your Apache Maven pom.xml file
in addition to
-OWB itself:
+[JBoss Arquillian][1] is a very popular testing framework for complex use
cases. You write your test with
+JUnit or TestNG but with the extended possibility to have fine grained control
over the managed environment.
+Basically Arquillian allows you to create artificial war / jar files with the
exact content you need for your test.
+Many powerful features are available in extensions. One such extension is
``Arquillian Drone``
+that allows you to test with a web-based user interface and ``Arquillian
Performance`` is another one
+that offers rich functionality aimed at performance testing.
+
+One of the main principles of ``Arquillian`` is to be portable and thus using
it to test applications that
+leverage OpenWebBeans is fully supported.
+
+To author a new ``Arquillian`` test you follow this rough flow:
+
+ - Create a new JUnit / TestNG test class
+ - Annotate the class with ``@RunWith(Arquillian.class)``
+ - Create a new deployment and include exactly what you need for that test.
+It's important that you add beans.xml to your test path and include it in the
deployment.
+ - Use @Inject (from the usual package) to obtain instances that you included
in the deployment
+ - Perform assertions on injected instances "normally".
+
+## Testing our Java SE / Servlet container project
+The best way to get started with ``Arquillian`` is to follow the official
[Getting Started][2] guide. However for testing
+OpenWebBeans standalone you will need to use the following adapter:
<dependency>
- <groupId>org.apache.deltaspike.cdictrl</groupId>
- <artifactId>deltaspike-cdictrl-api</artifactId>
- <version>${deltaspike.version}</version>
- <scope>test</scope>
+ <groupId>org.apache.openwebbeans.arquillian</groupId>
+ <artifactId>owb-arquillian-parent</artifactId>
+ <version>${owb.version}</version>
</dependency>
- <dependency>
- <groupId>org.apache.deltaspike.cdictrl</groupId>
- <artifactId>deltaspike-cdictrl-owb</artifactId>
- <version>${deltaspike.version}</version>
- <scope>test</scope>
- </dependency>
-
-## Why use CdiCtrl for your unit tests?
-
-Whenever you need to write unit tests for a full application, then you will
need to
-have a CDI container scann all your classes, create ``Bean<T>`` from it and
provide
-them for injection. All this can be done by either using JUnits ``@RunWith``
or
-by simply creating a common base class for your unit tests which boots up the
-container on your test classpath.
-
-There is no need to restart the container for each and every of your unit tests
-as this would cause a big performance loss. Instead it is usually sufficient
to
-use the CdiCtrls ``ContextControl`` mechanism to just stop and restart the
-respective CDI Contexts.
-
-Such a base class could look roughly like the following:
-
- :::java
- import org.apache.deltaspike.cdise.api.CdiContainer;
- import org.apache.deltaspike.cdise.api.CdiContainerLoader;
- import org.apache.deltaspike.core.api.projectstage.ProjectStage;
- import org.apache.deltaspike.core.util.ProjectStageProducer;
- import org.apache.deltaspike.core.api.provider.BeanProvider;
-
- public abstract class ContainerTest {
-
- protected static volatile CdiContainer cdiContainer;
- // nice to know, since testng executes tests in parallel.
- protected static int containerRefCount = 0;
-
- protected ProjectStage runInProjectStage() {
- return ProjectStage.UnitTest;
- }
-
- /**
- * Starts container
- * @throws Exception in case of severe problem
- */
- @BeforeMethod
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
-
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- cdiContainer.boot();
- cdiContainer.getContextControl().startContexts();
- }
- else {
- cleanInstances();
- }
- }
-
-
- public static CdiContainer getCdiContainer() {
- return cdiContainer;
- }
-
- /**
- * This will fill all the InjectionPoints of the current test class
for you
- */
- @BeforeClass
- public final void beforeClass() throws Exception {
- beforeMethod();
-
- // perform injection into the very own test class
- BeanManager beanManager = cdiContainer.getBeanManager();
-
- CreationalContext creationalContext =
beanManager.createCreationalContext(null);
-
- AnnotatedType annotatedType =
beanManager.createAnnotatedType(this.getClass());
- InjectionTarget injectionTarget =
beanManager.createInjectionTarget(annotatedType);
- injectionTarget.inject(this, creationalContext);
-
- // this is a trick we use to have proper DB transactions when
using the entitymanager-per-request pattern
- cleanInstances();
- cleanUpDb();
- cleanInstances();
- }
-
- /**
- * Shuts down container.
- * @throws Exception in case of severe problem
- */
- @AfterMethod
- public final void afterMethod() throws Exception {
- if (cdiContainer != null) {
- cleanInstances();
- containerRefCount--;
- }
- }
-
- /**
- * clean the NormalScoped contextual instances by stopping and
restarting
- * some contexts. You could also restart the ApplicationScoped context
- * if you have some caches in your classes.
- */
- public final void cleanInstances() throws Exception {
- cdiContainer.getContextControl().stopContext(RequestScoped.class);
- cdiContainer.getContextControl().startContext(RequestScoped.class);
- cdiContainer.getContextControl().stopContext(SessionScoped.class);
- cdiContainer.getContextControl().startContext(SessionScoped.class);
- }
-
- @AfterSuite
- public synchronized void shutdownContainer() throws Exception {
- if (cdiContainer != null) {
- cdiContainer.shutdown();
- cdiContainer = null;
- }
- }
-
- public void finalize() throws Throwable {
- shutdownContainer();
- super.finalize();
- }
-
-
- /**
- * Override this method for database clean up.
- *
- * @throws Exception in case of severe problem
- */
- protected void cleanUpDb() throws Exception {
- //Override in subclasses when needed
- }
-
- protected <T> T getInstance(Class<T> type, Qualifier... qualifiers) {
- return BeanProvider.getContextualReference(type, qualifiers);
- }
-
- }
-
-## Testing JavaEE applications
-
-You can also plug in a cdictrl backend for [Apache TomEE][2] whenever you need
to not only test CDI applications
-but a full JavaEE application which has EJBs, managed DataSources, JTA, etc
-The only thing you need to do is to replace your ``deltaspike-cdictrl-owb``
dependency in your pom with
-``deltaspike-cdictrl-openejb``. Since Apache TomEE and Apache OpenEJB both
contain OpenWebBeans as CDI container
-you will get all the OWB functionality plus other JavaEE functionality.
-
-You can pass DataSource configuration by simply providing a ``Properties``
instance to
-``CdiContainer.boot(dbConfiguration)`` in the beforeMethod method of the test
class above:
-
- :::java
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- Properties dbProperties = new Properties();
- String dbvendor = ConfigResolver.getPropertyValue("dbvendor",
"h2");
- URL dbPropertiesUrl = getClass().getResource("/db/db-" + dbvendor
+ ".properties");
- if (dbPropertiesUrl != null) {
- InputStream is = dbPropertiesUrl.openStream();
- try {
- dbProperties.load(is);
- }
- finally {
- is.close();
- }
- }
-
- cdiContainer.boot(dbProperties);
- }
- else {
- cleanInstances();
- }
- }
-
-The ``db/db-mysql.properties`` file for Apache OpenEJB (the former name of
TomEE) would look like:
-
- MYDS = new://Resource?type=DataSource
- MYDS.JdbcDriver = org.h2.Driver
- MYDS.JdbcUrl = jdbc:h2:file:/tmp/h2/myappdb
- MYDS.JtaManaged = true
- MYDS.UserName = sa
- MYDS.Password =
+## Testing your Java EE project
- [1]: http://deltaspike.apache.org
- [2]: http://tomee.apache.org
+In addition to the adapter described above TomEE offers serveral adapters for
working with TomEE. For more information visit [TomEE: Available Arquillian
Adapters][3].
+
+ [1]: http://arquillian.org/
+ [2]: http://arquillian.org/guides/getting_started/
+ [3]: http://tomee.apache.org/arquillian-available-adapters.html
\ No newline at end of file
Modified: openwebbeans/cms-site/trunk/content/testing_general.mdtext
URL:
http://svn.apache.org/viewvc/openwebbeans/cms-site/trunk/content/testing_general.mdtext?rev=1566395&r1=1566394&r2=1566395&view=diff
==============================================================================
--- openwebbeans/cms-site/trunk/content/testing_general.mdtext (original)
+++ openwebbeans/cms-site/trunk/content/testing_general.mdtext Sun Feb 9
20:35:21 2014
@@ -16,224 +16,35 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-# Testing your application with Apache DeltaSpike CdiCtrl
+# Testing strategies for projects that leverage CDI
-## About CdiCtrl
+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.
-``CdiCtrl`` is *not* part of Apache OpenWebBeans but a module of
-[Apache DeltaSpike][1].
+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.
-The ``CdiCtrl`` interface abstracts away all the logic to boot a CDI Container
-and controls the lifecycle of it's Contexts (Request Context, Session Context,
etc).
-
-The actual CDI Container is determined by using the
``java.util.ServiceLoader``.
-There are a few different implementations available. Besides Apache
OpenWebBeans
-there are also plugins for JBoss Weld and [Apache TomEE][2].
-
-## Adding OpenWebBeans CdiCtrl to your project
-
-The following are the dependencies you need in your Apache Maven pom.xml file
in addition to
-OWB itself:
-
- <dependency>
- <groupId>org.apache.deltaspike.cdictrl</groupId>
- <artifactId>deltaspike-cdictrl-api</artifactId>
- <version>${deltaspike.version}</version>
- <scope>test</scope>
- </dependency>
- <dependency>
- <groupId>org.apache.deltaspike.cdictrl</groupId>
- <artifactId>deltaspike-cdictrl-owb</artifactId>
- <version>${deltaspike.version}</version>
- <scope>test</scope>
- </dependency>
-
-## Why use CdiCtrl for your unit tests?
-
-Whenever you need to write unit tests for a full application, then you will
need to
-have a CDI container scann all your classes, create ``Bean<T>`` from it and
provide
-them for injection. All this can be done by either using JUnits ``@RunWith``
or
-by simply creating a common base class for your unit tests which boots up the
-container on your test classpath.
-
-There is no need to restart the container for each and every of your unit tests
-as this would cause a big performance loss. Instead it is usually sufficient
to
-use the CdiCtrls ``ContextControl`` mechanism to just stop and restart the
-respective CDI Contexts.
-
-Such a base class could look roughly like the following:
-
- :::java
- import org.apache.deltaspike.cdise.api.CdiContainer;
- import org.apache.deltaspike.cdise.api.CdiContainerLoader;
- import org.apache.deltaspike.core.api.projectstage.ProjectStage;
- import org.apache.deltaspike.core.util.ProjectStageProducer;
- import org.apache.deltaspike.core.api.provider.BeanProvider;
-
- public abstract class ContainerTest {
-
- protected static volatile CdiContainer cdiContainer;
- // nice to know, since testng executes tests in parallel.
- protected static int containerRefCount = 0;
-
- protected ProjectStage runInProjectStage() {
- return ProjectStage.UnitTest;
- }
-
- /**
- * Starts container
- * @throws Exception in case of severe problem
- */
- @BeforeMethod
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
-
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- cdiContainer.boot();
- cdiContainer.getContextControl().startContexts();
- }
- else {
- cleanInstances();
- }
- }
-
-
- public static CdiContainer getCdiContainer() {
- return cdiContainer;
- }
-
- /**
- * This will fill all the InjectionPoints of the current test class
for you
- */
- @BeforeClass
- public final void beforeClass() throws Exception {
- beforeMethod();
-
- // perform injection into the very own test class
- BeanManager beanManager = cdiContainer.getBeanManager();
-
- CreationalContext creationalContext =
beanManager.createCreationalContext(null);
-
- AnnotatedType annotatedType =
beanManager.createAnnotatedType(this.getClass());
- InjectionTarget injectionTarget =
beanManager.createInjectionTarget(annotatedType);
- injectionTarget.inject(this, creationalContext);
-
- // this is a trick we use to have proper DB transactions when
using the entitymanager-per-request pattern
- cleanInstances();
- cleanUpDb();
- cleanInstances();
- }
-
- /**
- * Shuts down container.
- * @throws Exception in case of severe problem
- */
- @AfterMethod
- public final void afterMethod() throws Exception {
- if (cdiContainer != null) {
- cleanInstances();
- containerRefCount--;
- }
- }
-
- /**
- * clean the NormalScoped contextual instances by stopping and
restarting
- * some contexts. You could also restart the ApplicationScoped context
- * if you have some caches in your classes.
- */
- public final void cleanInstances() throws Exception {
- cdiContainer.getContextControl().stopContext(RequestScoped.class);
- cdiContainer.getContextControl().startContext(RequestScoped.class);
- cdiContainer.getContextControl().stopContext(SessionScoped.class);
- cdiContainer.getContextControl().startContext(SessionScoped.class);
- }
-
- @AfterSuite
- public synchronized void shutdownContainer() throws Exception {
- if (cdiContainer != null) {
- cdiContainer.shutdown();
- cdiContainer = null;
- }
- }
-
- public void finalize() throws Throwable {
- shutdownContainer();
- super.finalize();
- }
-
-
- /**
- * Override this method for database clean up.
- *
- * @throws Exception in case of severe problem
- */
- protected void cleanUpDb() throws Exception {
- //Override in subclasses when needed
- }
-
- protected <T> T getInstance(Class<T> type, Qualifier... qualifiers) {
- return BeanProvider.getContextualReference(type, qualifiers);
- }
-
- }
-
-## Testing JavaEE applications
-
-You can also plug in a cdictrl backend for [Apache TomEE][2] whenever you need
to not only test CDI applications
-but a full JavaEE application which has EJBs, managed DataSources, JTA, etc
-The only thing you need to do is to replace your ``deltaspike-cdictrl-owb``
dependency in your pom with
-``deltaspike-cdictrl-openejb``. Since Apache TomEE and Apache OpenEJB both
contain OpenWebBeans as CDI container
-you will get all the OWB functionality plus other JavaEE functionality.
-
-You can pass DataSource configuration by simply providing a ``Properties``
instance to
-``CdiContainer.boot(dbConfiguration)`` in the beforeMethod method of the test
class above:
-
- :::java
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- Properties dbProperties = new Properties();
- String dbvendor = ConfigResolver.getPropertyValue("dbvendor",
"h2");
- URL dbPropertiesUrl = getClass().getResource("/db/db-" + dbvendor
+ ".properties");
- if (dbPropertiesUrl != null) {
- InputStream is = dbPropertiesUrl.openStream();
- try {
- dbProperties.load(is);
- }
- finally {
- is.close();
- }
- }
-
- cdiContainer.boot(dbProperties);
- }
- else {
- cleanInstances();
- }
- }
-
-The ``db/db-mysql.properties`` file for Apache OpenEJB (the former name of
TomEE) would look like:
-
- MYDS = new://Resource?type=DataSource
- MYDS.JdbcDriver = org.h2.Driver
- MYDS.JdbcUrl = jdbc:h2:file:/tmp/h2/myappdb
- MYDS.JtaManaged = true
- MYDS.UserName = sa
- MYDS.Password =
+
- [1]: http://deltaspike.apache.org
- [2]: http://tomee.apache.org
+### 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
Modified: openwebbeans/cms-site/trunk/content/testing_test-control.mdtext
URL:
http://svn.apache.org/viewvc/openwebbeans/cms-site/trunk/content/testing_test-control.mdtext?rev=1566395&r1=1566394&r2=1566395&view=diff
==============================================================================
--- openwebbeans/cms-site/trunk/content/testing_test-control.mdtext (original)
+++ openwebbeans/cms-site/trunk/content/testing_test-control.mdtext Sun Feb 9
20:35:21 2014
@@ -16,21 +16,26 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-# Testing your application with Apache DeltaSpike CdiCtrl
+# Testing your application with Apache DeltaSpike Test-Control
-## About CdiCtrl
+## About Test-Control
-``CdiCtrl`` is *not* part of Apache OpenWebBeans but a module of
-[Apache DeltaSpike][1].
-The ``CdiCtrl`` interface abstracts away all the logic to boot a CDI Container
-and controls the lifecycle of it's Contexts (Request Context, Session Context,
etc).
-
-The actual CDI Container is determined by using the
``java.util.ServiceLoader``.
-There are a few different implementations available. Besides Apache
OpenWebBeans
-there are also plugins for JBoss Weld and [Apache TomEE][2].
-
-## Adding OpenWebBeans CdiCtrl to your project
+``Test-Control`` is *not* part of Apache OpenWebBeans but a module of
+[Apache DeltaSpike][1]. It is based on another Deltaspike module called
``CdiCtrl``.
+``Test-Control`` is currently only available in snapshot releases of
Deltaspike.
+
+``CdiCtrl`` abstracts away all the logic to boot a CDI Container
+and controls the life cycle of it's Contexts (Request Context, Session
Context, etc).
+This module can be extremely powerful for CDI projects both for tests and
during runtime.
+It's a long time recommendation to use
+``CdiCtrl`` to write tests with low - medium complexity and we explain how
here:
+[Testing with cdiCtrl](source.html).
+
+With ``Test-Control`` the few steps you had to do on your own are taken cared
of for you. In a way ``Test-Control``
+puts ``CdiCtrl`` out of business in regards to testing.
+
+## Adding Deltaspike Test-Control to your project
The following are the dependencies you need in your Apache Maven pom.xml file
in addition to
OWB itself:
@@ -48,192 +53,30 @@ OWB itself:
<scope>test</scope>
</dependency>
-## Why use CdiCtrl for your unit tests?
+ <dependency>
+ <groupId>org.apache.deltaspike.cdictrl</groupId>
+ <artifactId>deltaspike-test-control-module-api</artifactId>
+ <version>${deltaspike.version}</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.deltaspike.cdictrl</groupId>
+ <artifactId>deltaspike-test-control-module-impl</artifactId>
+ <version>${deltaspike.version}</version>
+ <scope>test</scope>
+ </dependency>
-Whenever you need to write unit tests for a full application, then you will
need to
-have a CDI container scann all your classes, create ``Bean<T>`` from it and
provide
-them for injection. All this can be done by either using JUnits ``@RunWith``
or
-by simply creating a common base class for your unit tests which boots up the
-container on your test classpath.
-
-There is no need to restart the container for each and every of your unit tests
-as this would cause a big performance loss. Instead it is usually sufficient
to
-use the CdiCtrls ``ContextControl`` mechanism to just stop and restart the
-respective CDI Contexts.
-
-Such a base class could look roughly like the following:
-
- :::java
- import org.apache.deltaspike.cdise.api.CdiContainer;
- import org.apache.deltaspike.cdise.api.CdiContainerLoader;
- import org.apache.deltaspike.core.api.projectstage.ProjectStage;
- import org.apache.deltaspike.core.util.ProjectStageProducer;
- import org.apache.deltaspike.core.api.provider.BeanProvider;
-
- public abstract class ContainerTest {
-
- protected static volatile CdiContainer cdiContainer;
- // nice to know, since testng executes tests in parallel.
- protected static int containerRefCount = 0;
-
- protected ProjectStage runInProjectStage() {
- return ProjectStage.UnitTest;
- }
-
- /**
- * Starts container
- * @throws Exception in case of severe problem
- */
- @BeforeMethod
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
-
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- cdiContainer.boot();
- cdiContainer.getContextControl().startContexts();
- }
- else {
- cleanInstances();
- }
- }
-
-
- public static CdiContainer getCdiContainer() {
- return cdiContainer;
- }
-
- /**
- * This will fill all the InjectionPoints of the current test class
for you
- */
- @BeforeClass
- public final void beforeClass() throws Exception {
- beforeMethod();
-
- // perform injection into the very own test class
- BeanManager beanManager = cdiContainer.getBeanManager();
-
- CreationalContext creationalContext =
beanManager.createCreationalContext(null);
-
- AnnotatedType annotatedType =
beanManager.createAnnotatedType(this.getClass());
- InjectionTarget injectionTarget =
beanManager.createInjectionTarget(annotatedType);
- injectionTarget.inject(this, creationalContext);
-
- // this is a trick we use to have proper DB transactions when
using the entitymanager-per-request pattern
- cleanInstances();
- cleanUpDb();
- cleanInstances();
- }
-
- /**
- * Shuts down container.
- * @throws Exception in case of severe problem
- */
- @AfterMethod
- public final void afterMethod() throws Exception {
- if (cdiContainer != null) {
- cleanInstances();
- containerRefCount--;
- }
- }
-
- /**
- * clean the NormalScoped contextual instances by stopping and
restarting
- * some contexts. You could also restart the ApplicationScoped context
- * if you have some caches in your classes.
- */
- public final void cleanInstances() throws Exception {
- cdiContainer.getContextControl().stopContext(RequestScoped.class);
- cdiContainer.getContextControl().startContext(RequestScoped.class);
- cdiContainer.getContextControl().stopContext(SessionScoped.class);
- cdiContainer.getContextControl().startContext(SessionScoped.class);
- }
-
- @AfterSuite
- public synchronized void shutdownContainer() throws Exception {
- if (cdiContainer != null) {
- cdiContainer.shutdown();
- cdiContainer = null;
- }
- }
-
- public void finalize() throws Throwable {
- shutdownContainer();
- super.finalize();
- }
-
-
- /**
- * Override this method for database clean up.
- *
- * @throws Exception in case of severe problem
- */
- protected void cleanUpDb() throws Exception {
- //Override in subclasses when needed
- }
-
- protected <T> T getInstance(Class<T> type, Qualifier... qualifiers) {
- return BeanProvider.getContextualReference(type, qualifiers);
- }
-
- }
-
-## Testing JavaEE applications
-
-You can also plug in a cdictrl backend for [Apache TomEE][2] whenever you need
to not only test CDI applications
-but a full JavaEE application which has EJBs, managed DataSources, JTA, etc
-The only thing you need to do is to replace your ``deltaspike-cdictrl-owb``
dependency in your pom with
-``deltaspike-cdictrl-openejb``. Since Apache TomEE and Apache OpenEJB both
contain OpenWebBeans as CDI container
-you will get all the OWB functionality plus other JavaEE functionality.
-
-You can pass DataSource configuration by simply providing a ``Properties``
instance to
-``CdiContainer.boot(dbConfiguration)`` in the beforeMethod method of the test
class above:
-
- :::java
- public final void beforeMethod() throws Exception {
- containerRefCount++;
-
- if (cdiContainer == null) {
- // setting up the Apache DeltaSpike ProjectStage
- ProjectStage projectStage = runInProjectStage();
- ProjectStageProducer.setProjectStage(projectStage);
- cdiContainer = CdiContainerLoader.getCdiContainer();
-
- Properties dbProperties = new Properties();
- String dbvendor = ConfigResolver.getPropertyValue("dbvendor",
"h2");
- URL dbPropertiesUrl = getClass().getResource("/db/db-" + dbvendor
+ ".properties");
- if (dbPropertiesUrl != null) {
- InputStream is = dbPropertiesUrl.openStream();
- try {
- dbProperties.load(is);
- }
- finally {
- is.close();
- }
- }
-
- cdiContainer.boot(dbProperties);
- }
- else {
- cleanInstances();
- }
- }
-
-The ``db/db-mysql.properties`` file for Apache OpenEJB (the former name of
TomEE) would look like:
-
- MYDS = new://Resource?type=DataSource
- MYDS.JdbcDriver = org.h2.Driver
- MYDS.JdbcUrl = jdbc:h2:file:/tmp/h2/myappdb
- MYDS.JtaManaged = true
- MYDS.UserName = sa
- MYDS.Password =
+Note that deltaspike-cdictrl-openejb can substitute the deltaspike-cdictrl-owb
dependency if you are using TomEE.
- [1]: http://deltaspike.apache.org
- [2]: http://tomee.apache.org
+## Why use Test-Control for your unit tests?
+Test-Control offers the strong testing capabilities of ``CdiCtrl``
+but let's you focus on writing the actual tests alone. ``Test-Control`` is the
new lightweight champion for testing CDI and the required setup is very minimal.
+The testing flow is intuitive and follows the principles of other test
runners.
+
+## Examples and Getting started
+
+This information can be found here [Deltaspike documentation for
Test-Control](http://deltaspike.apache.org/test-control.html)
+
+ [1]: http://deltaspike.apache.org
