2. Inconsistencies or common problems of the Beandetection

• only classes of fields of the testclass annotated with @Mock are ignored. If you try to mock beans using this annotation at fields of helping beans, the corresponding class is given to Weld which at last leads to an error produced by the validator.
• Since CDI 1.1 beans.xml is not necessary to denote a ClassPath containing CDI-Beans. Beans in such Jars can never be included in a test-container.
• The algorithm of adding classes by inspecting @Inject and @Produces can sometimes help, sometimes not:
  • classes of fields and methods annotated by @Inject are automatically added to the container. This is reasonable, because these fields must be initialized by the container in any kind. But this automatism helps only, if that type is no abstract-class or interface. The same holds, if the class normally is created as subclass.
  • classes of fields and methods annotated by @Produces are further analyzed and added as classesToProcess. This is only necessary, if an injection of a class of that type is found. There is also the danger, that the added classes might not be necessary for injection, but itself leads to a tree of classes to process which the test-developer initially did not intend to add to the testing container.
• Parameter-Injects by producer and Constructors are not considered.
• A problem with weld, but what should be solved by a test-environment is: If you replace classes by Alternatives in your test, though the original class will not be instanciated, the weld-validation mechanism will check it's injects.