6

I use Deltaspike CdiControl to start up the CDI container for my unit tests. That works fine but there is a problem: If I use this approach for Maven web app the beans.xml end up in src/main/webapp/WEB-INF. That means it is not in the META-INF directory in the target folder during unit tests.

Since the unit tests itself are not a webapp but a Java SE run the WEB-INF directory is ignored. I can fix this by adding a second beans.xml to META-INF and/or copying the existing beans.xml to the right folder for unit tests. But this would mean I have to exclude it from the war manually so it seems a bit hackish.

Putting a beans.xml into src/test/resources/META-INF does not work because it will only allow the CDI components in target/test-classes to be detected.

This seems such a common problem that I assume somebody must have run into this before? Or is everybody having a separate Maven module for the components and/or the unit tests?

Gyanendra Dwivedi
  • 5,511
  • 2
  • 27
  • 53
fhossfel
  • 2,041
  • 16
  • 24
  • You could probably use some Maven magic to move the `beans.xml` around in `/target` for test execution part. But I would rather advice to take advantage of Weld's ability to disable discovery (no `beans.xml` needed) and then only add few beans you need in each given test. If it's truly unit testing, you don't need all of them anyway. You can also look at [weld-junit](https://github.com/weld/weld-junit) if you need a simple tool for Weld junit testing. – Siliarus Mar 05 '18 at 08:47
  • I have thought about this approach but it is problematic, too. I use mapstruct which generates CDI components. Therefore I don’t know exactly the classes I intend to use. The components provided by Deltaspike are another problem. If I manually load the classes a large part of the CDI functionality, namely the discovery and the wiring of components would remain untested. – fhossfel Mar 05 '18 at 12:17
  • That almost sounds like you are doing more of an integration testing rather than unit testing. For that purpose Arquillian could help as there you can use Shrinkwrap to provide any `beans.xml` you wish to (amongst other things). But that depends on your app (SE,EE?) and so forth. I am just tossing ideas around.... – Siliarus Mar 05 '18 at 12:32
  • can u have a single beans.xml in a common place, such src/main/resources, and under src/main/webapp/WEB-INF have another xml that imports it. in addition, have another (similar) xml under src/test/resources/META-INF that imports the beans.xml? – OhadR Mar 11 '18 at 13:43
  • The problem is that all this would affect the final war. It it were for testing only I would go that way but if I import the META-INF/beans.xml from WEB-INF/beans.xml I have to rely that any current or future application server will not look for a beans.xml in both places. Otherwise deployment would failed because of duplicated bean declarations. That seems like a risky bet to me. – fhossfel Mar 11 '18 at 13:47
  • @fhossfel never used any of the mentioned techonolgies but reading through the Test-Control Module docs of the DeltaSpike CDI see: https://deltaspike.apache.org/documentation/test-control.html they mention themselves that you need to add the beans.xml file to the "src/test/resources/META-INF/beans.xml" folder. If you want to reuse the same file you can do maven magic of copying file from its original location to the test sources and exclude the test resource (beans.xml here) during packaging of the war. – Konstantin Mar 16 '18 at 00:45
  • I idid that: "Putting a beans.xml into src/test/resources/META-INF does not work because it will only allow the CDI components in target/test-classes to be detected." The problem is that class in target'/class do not get detected so this kind of pointless. – fhossfel Mar 18 '18 at 10:53

0 Answers0