JUnit 5 extension #262
Comments
|
i would rather prefer a "complemented" instead of a "replaced" |
|
Sure 😄 |
|
@Guite |
|
I don't think so. |
|
Hi @tjeske , it would be great for Xpect moving forward, if Best regards, |
|
@trancexpress: 👍 I can have a look end of this week. |
|
I've been looking into replacing I assume the JUnit 5 addition will be using We have e.g. a test case that is similar to 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 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: #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 |
This change provides a JUnit 5 alternative of the JUnit 4 XpectRunner. To summarize the JUnit 4 specific code for Xpect tests, it looks like this: * XpectRunner takes the @XpectTestFiles test DSLs and generates a test case for each DSL test file, i.e. it generates test cases. * XpectFileRunner takes a DSL test file and generates test methods for a test case, these are coming from the XPECT statements (XpectInvocation or XjcTestMethod, I'm not sure which is what in the Xpect tests. * XpectTestRunner generates a test method for a XpectInvocation. * TestRunner generates a test method for a XjmTestMethod. The code JUnit 4 is "transformed" as follows: XpectRunner -> XpectDynamicTestFactory XpectFileRunner -> XpectDynamicTestCase XpectTestRunner -> XpectInvocationDynamicTest TestRunner -> XpectDynamicTest There is lots of supporting code that is not JUnit 4 specific, it remains functional and unchanged. The API proposal is to add a marker interface org.eclipse.xpect.dynamic.IXpectDynamicTestFactory, that is implemented by a test case in order to enable Xpect tests (based on JUnit 5) for that test case. There is also org.eclipse.xpect.dynamic.XpectDynamicTestCase, which has setUp() and tearDown() callbacks, called before reps. after each test method. We require these, since the JUnit 5 construct for generating tests, dynamic tests, doesn't have before/after callbacks (junit-team/junit5#1292 (comment), see also warning here: https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests). XpectRunner itself generates tests based on annotation values via JUnit 4 runners. XpectDynamicTestCase can be used by extending it and specifying the annotation @XpectReplace(XpectDynamicTestCase.class) at the extending class. Then importing the extended class at the client test case via e.g.: ... @XpectImport({MyXpectDynamicTestCase.class ...}) public class MyXpectTestCase implements IXpectDynamicTestFactory { ... Fixes: eclipse#262
|
#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 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. |
This change extracts parts of the singleton XpectRunner to another class, so that other implementations can set the values of the singleton. This change is required, in order to provide alternatives of XpectRunner, such as a JUnit 5 alternative, without depending on XpectRunner. Preparation for: eclipse#262
This change provides a JUnit 5 alternative of the JUnit 4 XpectRunner. To summarize the JUnit 4 specific code for Xpect tests, it looks like this: * XpectRunner takes the @XpectTestFiles test DSLs and generates a test case for each DSL test file, i.e. it generates test cases. * XpectFileRunner takes a DSL test file and generates test methods for a test case, these are coming from the XPECT statements (XpectInvocation or XjcTestMethod, I'm not sure which is what in the Xpect tests. * XpectTestRunner generates a test method for a XpectInvocation. * TestRunner generates a test method for a XjmTestMethod. The code JUnit 4 is "transformed" as follows: XpectRunner -> XpectDynamicTestFactory XpectFileRunner -> XpectDynamicTestCase XpectTestRunner -> XpectInvocationDynamicTest TestRunner -> XpectDynamicTest There is lots of supporting code that is not JUnit 4 specific, it remains functional and unchanged. The API proposal is to add a marker interface org.eclipse.xpect.dynamic.IXpectDynamicTestFactory, that is implemented by a test case in order to enable Xpect tests (based on JUnit 5) for that test case. There is also org.eclipse.xpect.dynamic.XpectDynamicTestCase, which has setUp() and tearDown() callbacks, called before reps. after each test method. We require these, since the JUnit 5 construct for generating tests, dynamic tests, doesn't have before/after callbacks (junit-team/junit5#1292 (comment), see also warning here: https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests). XpectRunner itself generates tests based on annotation values via JUnit 4 runners. XpectDynamicTestCase can be used by extending it and specifying the annotation @XpectReplace(XpectDynamicTestCase.class) at the extending class. Then importing the extended class at the client test case via e.g.: ... @XpectImport({MyXpectDynamicTestCase.class ...}) public class MyXpectTestCase implements IXpectDynamicTestFactory { ... Fixes: eclipse#262
This change provides a JUnit 5 alternative of the JUnit 4 XpectRunner. To summarize the JUnit 4 specific code for Xpect tests, it looks like this: * XpectRunner takes the @XpectTestFiles test DSLs and generates a test case for each DSL test file, i.e. it generates test cases. * XpectFileRunner takes a DSL test file and generates test methods for a test case, these are coming from the XPECT statements (XpectInvocation or XjcTestMethod, I'm not sure which is what in the Xpect tests. * XpectTestRunner generates a test method for a XpectInvocation. * TestRunner generates a test method for a XjmTestMethod. The code JUnit 4 is "transformed" as follows: XpectRunner -> XpectDynamicTestFactory XpectFileRunner -> XpectDynamicTestCase XpectTestRunner -> XpectInvocationDynamicTest TestRunner -> XpectDynamicTest There is lots of supporting code that is not JUnit 4 specific, it remains functional and unchanged. The API proposal is to add a marker interface org.eclipse.xpect.dynamic.IXpectDynamicTestFactory, that is implemented by a test case in order to enable Xpect tests (based on JUnit 5) for that test case. There is also org.eclipse.xpect.dynamic.XpectDynamicTestCase, which has setUp() and tearDown() callbacks, called before reps. after each test method. We require these, since the JUnit 5 construct for generating tests, dynamic tests, doesn't have before/after callbacks (junit-team/junit5#1292 (comment), see also warning here: https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests). XpectRunner itself generates tests based on annotation values via JUnit 4 runners. XpectDynamicTestCase can be used by extending it and specifying the annotation @XpectReplace(XpectDynamicTestCase.class) at the extending class. Then importing the extended class at the client test case via e.g.: ... @XpectImport({MyXpectDynamicTestCase.class ...}) public class MyXpectTestCase implements IXpectDynamicTestFactory { ... Fixes: eclipse#262
The
XpectRunnerclass needs to be replaced by an extension used with@ExtendWithin JUnit 5. Is there suggestion how to use a "migration mode" until a new Xpect release is available?The text was updated successfully, but these errors were encountered: