Hello Apache OFBiz Dev Members, I have been working on adding JUnit 5 (Jupiter) support to framework/testtools, and using it to migrate every remaining JUnit3 test file in the plugins folder. I want to share why this matters and what it makes possible, and get the OFBiz community input before I look at the much larger applications folder.
Taken together, this moves Apache OFBiz's Integration Testing capability from moderate to genuinely extensive - parameterized tests, explicit lifecycle control, deterministic execution ordering, and fail-fast diagnostics now run natively against the very same entity and service engine our business logic already depends on, directly inside the real integration container rather than a mocked-out substitute. *Why move off JUnit 3* 1) JUnit 3 test classes are invisible to plain gradlew test today - dependencies.gradle registers only the junit-jupiter-engine, with no junit-vintage-engine bridge, so a JUnit3 class never appears in a gradlew test run as passed, failed, or even skipped; it is simply never discovered, and every one of our ~86 remaining JUnit3 files has been silently relying on that gap for years. 2) JUnit 3 forces every test class to extend TestCase/EntityTestCase/OFBizTestCase and discovers tests by reflection on a testXxx naming convention, so there is no real lifecycle, no parameterization, and no way to add a test-only helper without adding it to the shared base class. 3) JUnit 3 has been unmaintained for past many years, while JUnit 5 is the actively developed, industry-standard test framework most contributors already know, which lowers the ramp-up cost for anyone new to the OFBiz codebase. 4) Some of our JUnit3 files are not really integration tests at all - a scan of all 86 candidate files found four (DateUelTest, MathUelTest, MiscUelTest, StringUelTest in framework/base) that never touch the entity or service engine, yet still pay the full ofbiz --test container boot cost on every run purely because of the inherited constructor convention; migrating those to plain Jupiter tests lets them run in seconds under gradlew test instead of minutes under testIntegration, and that migration has already been merged. 5) The migration does not force a rewrite of anything - junit-test-suite and jupiter-test-suite test-cases run side by side inside the exact same test-suite, sharing the same Delegator/LocalDispatcher and the same suite-level rollback, so JUnit3 files keep working exactly as before for as long as we want them to. *What the new infrastructure gives Integration tests specifically* 6) JunitJupiterTest is a composed annotation that keeps a container-backed Jupiter test out of plain gradlew test (via a jupiterIntegration tag exclusion) while still registering it for testIntegration through a new jupiter-test-suite testdef element, so the two Gradle pipelines stay cleanly separated. 7) JupiterTestHelper is a mixin interface that gives getDelegator(), getDispatcher(), getUserLogin(), from(), and select() with zero constructor and zero field boilerplate, so a migrated test class becomes a plain POJO instead of being forced into the OFBizTestCase inheritance chain. 8) @Test methods get real, descriptive, free-form names instead of being constrained to a testXxx prefix, and @Disabled lets a test be turned off with a visible, reported reason instead of being commented out or silently deleted. 9) @ParameterizedTest with @CsvSource lets one method cover many input variations, replacing the copy-pasted testFoo1/testFoo2/testFoo3 style still common across the JUnit3 suite. 10) Method execution order is now explicit and enforced project-wide via MethodOrderer.OrderAnnotation, closing a real gap in JUnit 3, which never guaranteed any method order at all; converting scrum's test files surfaced a genuine pre-existing bug that depended on JUnit 3's undocumented, accidentally-stable reflection order, and @Order made that dependency visible and fixable instead of silently masked. 11) A Jupiter test class with no JunitJupiterTest annotation and no JupiterTestHelper needs no OFBiz container at all and runs directly under gradlew test, so the same infrastructure now supports both true unit tests and container-backed integration tests cleanly, something the old OFBizTestCase-based model could never offer. 12) Every injection failure mode fails loudly instead of silently - running outside the container, enabling unsupported parallel execution, or misnaming a delegator/dispatcher field all throw a clear, specific error at the injection site now, backed by a dedicated JupiterInjectionGuardsTest, instead of surfacing later as a confusing null pointer. *Where things stand and what is next* 13) The infrastructure itself (JupiterTestExtension, JupiterTestHelper, JunitJupiterTest, the jupiter-test-suite testdef element) is implemented, hardened, and already proven on real business logic, not just the example plugin - all four migrated plugins suites (assetmaint, ecommerce, lucene, scrum) pass in full under testIntegration. 14) The plugins folder is now fully migrated - all twelve remaining real JUnit3 test files across assetmaint, ecommerce, lucene, and scrum have been converted to Jupiter, with the plugins/example component's original JUnit3 test kept intentionally in place as a side-by-side old-versus-new reference. 15) The applications folder is intentionally not next as a mandatory sweep - there are roughly 86 JUnit3 files and 555 test methods left there, and the plan is to keep migration opportunistic, converting a file only when there is already a concrete reason to touch it, rather than a mechanical bulk PR that would conflict with everyone else's in-flight work. 16) I plan to let the JUnit5-based Integration tests in plugins soak for the next few days before starting on applications, and would welcome thoughts from anyone who has opinions on scope, pace, or files worth prioritizing first. PRs: https://github.com/apache/ofbiz-framework/pull/1529 https://github.com/apache/ofbiz-plugins/pull/344 I look forward to getting the OFBiz community's support on this JUnit 5(Jupiter) migration initiative for integration tests in Apache OFBiz. Thank you! 👍 -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com https://www.linkedin.com/in/ashishvijaywargiya/
