Open Guite opened 5 years ago
i would rather prefer a "complemented" instead of a "replaced"
Sure :smile: The replacement is done from usage-perspective. Of course Xpect should not drop JUnit 4 support.
@Guite Is there a workaround to run Xpect with JUNit 5 and the @ExtendWith annotation?
I don't think so.
Hi @tjeske ,
it would be great for Xpect moving forward, if XpectRunner
has a JUnit 5 equivalent. Do you have bandwidth to provide one?
Best regards, Simeon
@trancexpress: 👍 I can have a look end of this week.
I've been looking into replacing XpectRunner
in our own code (in case it takes a while to provide a JUnit 5 equivalent in Xpect), that seems to not be simple due to it being a singleton: org.eclipse.xpect.runner.XpectRunner.INSTANCE
I assume the JUnit 5 addition will be using TestFactory
from JUnit 5, since that seems to be the way to generate tests on-the-fly with JUnit 5 (XpectRunner
itself also defines tests on-the-fly). Unfortunately, TestFactory
targets methods - its unclear to me how the JUnit 5 construct for Xpect tests should look like.
We have e.g. a test case that is similar to XtextTests
(annotated with @RunWith(XpectRunner.class
), but the test case also extends our base class for all tests.
Providing a base class that has factory methods therefore doesn't work for us. The way it looks to me, Xpect is forced to provide a static method to delegate to? E.g. something like this will need to be added to test cases that previously had XpectRunner
or extend from a class annotated with XpectRunner
:
@TestFactory
Stream<DynamicTest> dynamicTests() {
return XpectDynamicTestFactory.dynamicTests(this.getClass());
}
This seems rather clunky, but I don't see any other option?
Before adding any actual new API, it might be good to discuss this...
My attempts are found here:
https://github.com/trancexpress/Xpect/tree/XpectRunner_JUnit5
See: https://github.com/eclipse/Xpect/pull/343
I'm able to run some tests with this. Will have to check with more tests though; that requires also porting our JUnit 4 constructs (that we have on top of XpectRunner
) to JUnit 5...
https://github.com/eclipse/Xpect/pull/343 is ready for reviewing.
Ideally we get some feedback on how the new API looks like, though I'm not sure how much of the feedback I'll be able to accommodate. I'm taking care of the JUnit 5 test migration for the product I work on, I'm sure there can be plenty of other uses of XpectRunner
that will be difficult to support with JUnit 5.
And of course, likely/arguably we should move Xpect tests themselves to JUnit 5... Or decide how the JUnit 5 functionality is to be tested, in parallel to the JUnit 4 functionality.
The
XpectRunner
class needs to be replaced by an extension used with@ExtendWith
in JUnit 5. Is there suggestion how to use a "migration mode" until a new Xpect release is available?