JUnit 5 support #220
Comments
|
Main problem: the |
|
Seems JUnit5 does not support the scenario that a single test is run in a different classloader. In this issue, I found a link to https://junit.org/junit5/docs/snapshot/user-guide/#launcher-api-launcher-interceptors-custom which could be used to change the classloader. But as far as I understand it, this is done for the whole testsuite, while we would need it only for a few tests in the testsuite. @rhusar Do you have any idea? |
|
I am not that versed in JUnit 5 and also only recently we fixed the remaining issues in Arquillian with injection in JUnit 5. Though, for now we could support JUnit 5 with classloader for the whole testsuite and add notes not to combine Warp tests with other tests in a single surefire/failsafe execution. Not ideal, but at least getting started somewhere. |
|
We could extract all tests that require the SeparatedClassloader approach to an extra project. In the first step, this old project could still be run with JUnit4. What do you think? |
We do need to support both JUnit 4 and JUnit 5 within the same project branch since both of those versions are widely used. So that means we might need a new Warp module for JUnit 5 but definitely a new JUnit 5 surefire execution. Perhaps a common module that has the common JUnit classes. |
|
Maybe I have misunderstanding here, but I think that JUnit is only used in the internal testsuite of warp. All dependencies have scope "test". There is no code of the extension itself that uses JUnit. So a user of the extension should be free to use JUnit4 or JUnit5. Or is our test dependency on JUnit propagated to all clients using the warp BOM? |
|
@WolfgangHG You might be right, I have not looked at this yet - the scope of the issue is really 'Investigate state of JUnit 5 support.' - as this is mostly implemented as an ARQ extension, then perhaps it just works? In that case, maybe a smoke test running with JUnit 5 would suffice. |
|
@rhusar I gave my small test project (still JavaEE8, references Warp 1.1.0) a try and converted it to JUnit 5 - no problems in this simple test. The test class is found at "/StatelessMaven-web/src/test/java/de/hsrm/cs/javaee8/statelessmaven/web/test/WarpIT.java". |
|
@rhusar I tried to convert the test suite to JUnit 5, code can be found in my fork: https://github.com/WolfgangHG/arquillian-extension-warp/tree/junit5 The projects "ftest" and "jsf-ftest" work again. But there are several tests in the "impl" project that fail. The reason seems to be that injection does not happen. As you wrote that the scope of this issue is "investigate whether something needs to be done to support JUnit5 on the consumer side" (and my opinion is that it works without changes), I can create a new issue for converting the test suite. |
I am not up to speed why the SeparatedClassloaderRunner is needed especially since there is no javadoc :-) But I can have a look later.
We can theoretically do these in parts too, i.e. per module.
There was problem with injecting to methods, but not to fields. I can have a look.
OK, that's good news! So the SeparatedClassloaderRunner is part of the project testing infrastructure - not something that users need to do. We can keep using this issue for the upgrade, if we want to proceed with that. |
|
Yes, SeparatedClassLoaderRunner is in the "test" path, so I assume it is only used for internal tests and not public api. My plan is to experiment with the JUnit5 |
|
The LauncherInterceptor does not seem to work, as it is initialized only once per test suite. I asked a question in the JUnit5 repository: junit-team/junit5#4203 |
Investigate state of JUnit 5 support.
The text was updated successfully, but these errors were encountered: