-
Notifications
You must be signed in to change notification settings - Fork 9
0. Internal Mechanisms in Creation of a Test Container
Rules about building up a testing environment
Creation of new tests for complex modules sometimes can be quite cumbersome. In preparation of making that easier, the current mechanism will be described below, as analyzed by looking at the code.
The tests are started inside a Weld-Standalone-Engine-Container.
To start the container a subclass of a org.jboss.weld.environment.se.Weld-Object is created. The Container is created by calling initialize at this object.
During initialize the overloaded method createDeployment is called. That gives the possibility to define which beans should be included.
As soon as the container is created a JNDI-Factory of type: org.jglue.cdiunit.internal.naming.CdiUnitContextFactory is registered and the Beanmanager as it was created by the container during initialize is registered by the name "java:comp/BeanManager".
If during initialization an exception is encountered and the test-method does cover the type of the exception, the exception gets ignored. The container is not started and the testmethod returns immediately. This makes it possible to check for expected exceptions during the tests of cdi-unit by using @Test(expected ...)
After each test the container is closed by calling Weld##shutdown.
Weld##createDeployment creates an object derived from the class: org.jboss.weld.bootstrap.spi.Deployment.
During creation an algorithm is used to discover the classes which should comprise the container. This algorithm
- first analyzes the testclass,
- looks at the superclasses of the testclass,
- evaluates special annotations
- evaluates injectionpoints of the discovered classes
it will be discribed in more detail below. In the following it will be refered to by the name Beandetection.
In the case of cdi-unit-tests, this object contains a single org.jboss.weld.bootstrap.spi.BeandeploymentArchive with the following features:
id: cdi-unit plus random UUID
beanClasses: The beans that should comprise the container:
- some preconfigured Beans to be included to support some special features
- the Beans as they are discovered by Beandetection. Weld will be informed that these classes belong to just one BeanDeploymentArchive, even if they might be contained in the target-folder of the current maven run or be located in JAR-Files added as dependencies to the project.
beansXml: a description of the beans.xml as it would be defined if the BeanDeploymentArchive was real
- a list of Interceptorclasses containing
- default - designed by cdi-unit and as
- discovered during analyzing the Test-Class (Beandetection)
- a list of Decorator classes (Beandetection)
- a list of activated alternative classes(Beandetection)
- beanDiscoveryMode: BeanDiscoveryMode.ANNOTATED: But: The deployment already delivers all discovered beans. Therefore this mode should not be an issue. TODO to be tested
- a list of alternative stereotypes
- ProducesAlternative defined by cdi-unit
- Stereotype-Annotations discovered Beandetection but only if they are also annotated by @Alternative
- Scanning: EMPTY_SCANNING TODO meaning?
- an URL "file:cdi-unit"
- a version: "cdi-unit"
- isTrimmed: false (weld 2.4) TODO meaning?