Great initiative, Ashish. This is a much-needed improvement for the OFBiz integration testing ecosystem.
+1 Regards, Arun Patidar On Fri, Jul 31, 2026 at 11:19 AM Ashish Vijaywargiya < [email protected]> wrote: > 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/ >
