0

Currently I am trying to integrate JUnit5.3.0-RC1 into a Weld-SE-Testframework ejb-cdi-unit.

The first solution on JUnit5.2.0 available in ejb-cdi-unit:1.1.15 restricts the TestInstance-Classes somewhat concerning CDI. I can only allow @Inject. That helps already very much, but see

Now trying to implement the TestInstanceFactory, to avoid the mentioned restrictions, I encounter problems with example.

You can see a Testclass ServiceTest5 working in Lifecycle PER_CLASS and two nested inner classes of which one is working in Lifecycle PER_METHOD.

The innerclasses are currently disabled to avoid mails from travis-ci.

I would expect, that before the method ServiceTest5#WhenSomeEntitiesInDbExist#cantReadTestDataUsingServiceInRequiredNew is called, a completely new TestInstance of ServiceTest5 is created using the TestInstanceFactory implemented in JUnit5Extension, since the nested innerclass WhenSomeEntitiesInDbExist has Lifecycle PER_METHOD.

That is not the case. Is that by design, or a bug in the release candidate?

aschoerk
  • 3,333
  • 2
  • 15
  • 29
  • Was the TestInstance of ServiceTest5 created through the TestInstanceFactory at all? – seanf Aug 29 '18 at 07:42
  • Here's a permalink for the example: https://github.com/1and1/ejb-cdi-unit/blob/772cb6dbbae13b1e11256afe8ad5b2a880234ce9/examples/ex1-1entity5/src/test/java/com/oneandone/ejbcdiunit/example1_5/ServiceTest5.java#L130 – seanf Aug 29 '18 at 07:43
  • Yes, otherwise the working methods would have no EntityManager or UserTransaction. – aschoerk Aug 29 '18 at 07:53
  • Sorry, I meant the inner class WhenSomeEntitiesInDbExist. Did it go through the factory? – seanf Aug 29 '18 at 08:04
  • No, only through postProcessTestInstance. The Factory does not create inner classes. I think the Interface would not work. – aschoerk Aug 29 '18 at 10:09
  • More discussion here: https://github.com/junit-team/junit5/issues/1566 – seanf Aug 29 '18 at 15:21

0 Answers0