Currently blocked by junit-team/junit5#672

Once that is done, supporting JUnit 5 should be easy.

+1

Other possibly related JUnit issues:

• Introduce BeforeTestInstantiationCallback extension API junit-team/junit5#839
• Provide a way to specify my own test method runner junit-team/junit5#1248 (Arquillian)

Now that junit-team/junit5#672 has been implemented, do you plan to support JUnit 5?

Perhaps junit5 might be a solution for cdi-unit as well. Examples can be seen in tests. A first (not yet released) implementation of the support can be seen in JUnit5Extension

Perhaps junit5 might be a solution for cdi-unit as well. Examples can be seen in tests . A first (not yet released) implementation of the support can be seen in JUnit5Extension

@aschoerk In other words, make the CDI-Unit Test class not a bean, but just @Inject its fields? Is that the basic approach?

That would certainly fit with these environments that insist on creating the Test object, but CDI-Unit itself and often CDI-Unit-based tests make use of CDI interceptors, eg for @InRequestScope or DeltaSpike's @Transactional. There might be a way to run the interceptors by some unusual means, but I'm not sure if that is possible.

@kalgon said:

Now that junit-team/junit5#672 has been implemented, do you plan to support JUnit 5?

Specifically TestInstanceFactory: junit-team/junit5#672 (comment) and junit-team/junit5#1443

Marked as "experimental", included in JUnit 5.3.0-RC1, not yet part of a GA release.

There's this still waiting to be implemented, to control the ClassLoader, but I don't think it's needed by CDI-Unit (or Weld): junit-team/junit5#201

I think we'll have to implement some sort of CdiUnitExtension which implements TestInstanceFactory (and some other Extension interfaces), then run tests with @ExtendWith(CdiUnitExtension.class) instead of @RunWith(CdiRunner.class).

So it looks like it may be possible now. I'm not using JUnit 5 myself yet, so I can't say when I'll find the time to investigate further.

That would certainly fit with these environments that insist on creating the Test object, but CDI-Unit itself and often CDI-Unit-based tests make use of CDI interceptors, eg for @InRequestScope

I had that problem and solved it by using a regular class see testRequestScope() in
TestCdiUnitRunner

I tried TestInstanceFactory in JUnit 5.3.0-RC1 but sadly it did not fit in my current intellij-Environment. So I dropped that approach. I fear it also might not be so easy to handle the inner classes since those can not be created using weld. But we will see. At the moment JUnit5 promises to allow very well structured Tests.

@aschoerk

I tried TestInstanceFactory in JUnit 5.3.0-RC1 but sadly it did not fit in my current intellij-Environment. So I dropped that approach.

Can you elaborate? What sort of problems did you see?

I fear it also might not be so easy to handle the inner classes since those can not be created using weld. But we will see. At the moment JUnit5 promises to allow very well structured Tests.

In your picture, I gather CanHandleValidationExceptions, CanMapOtherExceptions and GreenPathTests are non-static inner classes of MobileInformationServiceEjbCdiUnit5Test?

Can you elaborate? What sort of problems did you see?

Sorry, no at the moment not. In the current snapshot I switched to 5.3.0-RC1, introduced a primitive factory and the tests seem to work. I need to look further into that. Perhaps the intellij-installation on the other computer is slightly different.

are non-static inner classes of MobileInformationServiceEjbCdiUnit5Test

yes, tests starting with [#] are different parameters generated by Method. Btw. the inner classes work in per_class-lifecycle (necessary to be able to provide a non static parameter generating method in the class) the outer level is per_method as default.

Implementing TestInstanceFactory look quite well, but there ssem to be yet problems, when Life-Cycle gets changed in inner classes. see stackoverflow

@aschoerk Did you report your problem to the junit team? It could be fixed before 5.3 is released.

@kalgon not yet, I followed a link in the user guide. As soon as I am back in WiFi I will move the stackoverflow issue to github

Update: I have a basic proof of concept working. It's a total hack job with duplicated code from CdiRunner, minus some of its error handling (and JNDI support). Refactoring still to be done. Code to come in a while.

I haven't yet tested support for all the annotations like AdditionalClasses, ActivatedAlternatives, Mock, SupportJaxRs, SupportEjb, SupportDeltaspike, ProducerConfig, but I hope they'll just work, as long as the annotations are not on an inner class. Mock support for inner classes will probably need a bit of extra work.

There is one problem though: the TestInstanceFactory never gets any information about the test method, even for org.junit.jupiter.api.TestInstance.Lifecycle#PER_METHOD, which means ProducerConfigExtension can't work as currently implemented. I'm not sure if this can be worked around or not. Maybe JUnit 5 Parameterized Tests will suffice.

Interceptors are working for outer classes, but inner classes only support field injection (A: because of the above TestInstanceFactory weirdness with inner classes, and B: it seems impossible to create inner classes as beans). I'm starting to wonder seriously about the possibility of running test method interceptors without Weld's help... But probably as a later enhancement.

I haven't fixed the copy-paste crimes or other deficiencies, but in case anyone wants to try it, I've uploaded the mess here: https://github.com/seanf/cdi-unit/tree/junit5

Main code here: https://github.com/seanf/cdi-unit/blob/junit5/cdi-unit/src/main/java/org/jglue/cdiunit/CdiExtension.java

Sample JUnit 5 test here: https://github.com/seanf/cdi-unit/blob/junit5/cdi-unit/src/test/java/org/jglue/cdiunit/CdiExtensionTest.java

If anyone wants to hack on it, send a PR to my seanf fork, branch name junit5.

@aschoerk's issue is junit-team/junit5#1566. See also junit-team/junit5#1567

Any update on this?

Since this project has been inactive for quite a while, I decided to implement a JUnit 5 extension for CDI Unit in a separate project cschabl/cdi-unit-junit5. It is intended to serve as a kludge as long as CDI Unit itself doesn't provide one.
It is available on Maven Central and currently supports basic use cases.

Hi @cschabl,

Did you manage to convert a complete set of tests from CDI-Unit to JUnit 5?
Or, let's put it another way - do you have a representative test suite to confirm the implementation?

Hi @ikysil ,
yes. A test suite of a servlet application using CDI (Weld 3.1), consisting of a couple dozens of CDI-Unit-run test classes having a couple hundreds of tests altogether.

Hi @cschabl ,

I've seen your project at https://github.com/cschabl/cdi-unit-junit5
Would you mind bringing the code under cdi-unit umbrella?

Hi @ikysil , no I don't mind.
I've noticed the CDI Unit project became active again and I've changed my job recently and won't work with CDI anymore.

Do you want me to create a PR or do you like to copy and adjust the code for the cdi unit project?

Hi @cschabl ,

Thank you for the feedback.

Both will work for me as long as you agree.
I see the need to restructure the modules in cdi-unit to better isolate the supported testing frameworks and versions of Weld. Therefore I don't see this integration happening before the next minor release of cdi-unit.

Thank you for the efforts, I will work on restructuring and integrating your code.

Hi @ikysil , let me know when you're done.

Hi @ikysil ,
just wanted to ask for a quick status update on the JUnit 5 integration. We are currently weighing our options here if it makes sense to wait or not. Thanks!

We have switched to https://github.com/weld/weld-junit

You know that ioc-unit supports junit5?
The definition of the test-container is more in cdi-unit-style.
See https://github.com/1and1/ioc-unit/blob/master/examples2/ex1-1entity5/src/test/java/com/oneandone/iocunitejb/example1_5/ServiceTest5.java

For the moment, no development around JUnit 5 were done at all - except this project by @cschabl
https://github.com/cschabl/cdi-unit-junit5

Would love to see Jupiter support in CDIUnit. The other project (cdi-unit-junit5) doesn't seem to support jakarta name spaces.

I'm positive about JUnit Jupiter implementation after doing #74 and #276 .

The only feature missing is IsolationLevel.PER_CLASS support.
I will look into it after adding JUnit Jupiter support.

Stay tuned!

Feel free to play with changes at #287

I've been working on a JakartaEE-compatible version of cdi-unit-junit5 based on CDI-Unit 5.0.0.EA2, simultaneously.
Well, I was too slow. But I released it anyway as cschabl.cdi-unit-junit5/[email protected].
Additionally, I released a maintenance release 1.0 based on CDI-Unit 4.4, leveraging #173.

Hi @cschabl ,

Could you please chime in at discussion #290 ?