dweiss opened a new pull request, #16027: URL: https://github.com/apache/lucene/pull/16027
This patch adds a new class `LuceneTestCaseJupiter`, which can be used as a direct replacement for LuceneTestCase to convert test classes to JUnit5/jupiter. The test-framework module exports both junit4 and junit5/jupiter dependencies. `LuceneTestCase` remains the parent abstract class for JUnit4 tests. `LuceneTestCaseJupiter` is the parent class to extend from for JUnit5 support. # please read There are some key things to observe here: * If you decide to inherit from LuceneTestCaseJupiter, all test cases must be proper Jupiter tests, typically this means methods must be annotated with `@Test`. **Method prefix `test*` is not sufficient**. Methods that are named `test*` but are not tests will cause validation errors at runtime (there is a test for this...). * You can use parameterized tests, dynamic tests, etc. All these are supported. * You *must not* call the static `random()` method on the parent class, even though it is there. Add a `Random` parameter to your test methods or callbacks - it will be automatically injected by the test framework. See the `memory` module tests for some examples. * Use `@BeforeEach`, `@AfterEach` and other junit5-specific callback annotations instead of `setUp` and `tearDown` methods. These methods are also there, but they should be deprecated and removed at some point. * Static utility methods have been pulled up to a parent class called `LuceneTestCaseParent` but you should reference them either without an explicit type or via the type of the parent class for your test framework of choice. The parent class may be removed in the future. This patch *should work as a drop-in-replacement* for any subproject using test-framework. A lot of (human) thought went into making sure both the junit4 and junit5 base class work pretty much the same way (there are still some pieces missing but they are not critical). # what next? Now, if we want to move forward and actually convert all the existing tests to junit5 (and eventually drop junit4) this becomes a more problematic issue because it affects all the downstream projects (solr, elasticsearch) - any tests inheriting from test framework util's "base" classes (like the base class for token filters, etc.) will require updating. If they do non-trivial things, the update may be non-trivial too. # discussion It took me an enormous amount of time to get this to work with both frameworks at the same time. Not everything is pretty internally but I don't see how certain things can be solved while keeping backward compatibility (and without changing *a lot* of existing codebase). Now... For all the benefits junit5 provides (there are many nice things about it), I also think there is not that much visible improvement... I mean - for all the bells and whistles of junit5, it's still just a test framework for running test cases. We can't utilize parallel tests (because we use static contexts everywhere), we don't really do any fancy things. It's mostly the same. If you think this is complicating things with no clear benefit, please do speak up. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
