Hello Dev Members, Following up on my July 31 update, I'm glad to report that the JUnit 3 to JUnit 5 (Jupiter) migration for Apache OFBiz Integration tests is now complete. Last week I migrated the remaining JUnit3 integration test files in the "applications" and "framework" folders, *which closes out the plan I shared then and the broader vision from my original May 2026 thread on modernizing our JUnit tooling - * https://lists.apache.org/thread/ssh1m7s3qyn3126qm0q7d7n6shrvmcw2*. *
1) Applications folder is fully migrated (PR #1541): all 62 testdef-wired JUnit3 test classes across accounting, content, manufacturing, marketing, order, party, product, and workeffort converted to Jupiter, using the JupiterTestHelper/JunitJupiterTest infrastructure introduced in PR #1529. 2) Framework folder is fully migrated (PR #1542): all 20 testdef-wired JUnit3 test classes across base, common, entity, minilang, rest-api, service, webapp, and widget were converted to Jupiter. 3) This migration also cleaned up along the way: 27 test files that were sitting under src/main instead of src/test got moved to their correct location (manufacturing 3, order 5, product 3 in applications; common 1, entity 4, minilang 1, rest-api 1, service 8, widget 1 in framework), and 7 dead no-op setUp()/tearDown() overrides were removed. 4) Real value beyond the mechanics: converting applications' tests surfaced 8 pre-existing test-order-dependency bugs that JUnit 3's nondeterministic method ordering had been silently masking - manufacturing/ProductionRunTests, order/QuoteTests, party (3x), and product/ProductTest. Each was verified as pre-existing, then fixed. Jupiter's deterministic @Order is what made these visible in the first place. 5) Combined with the plugins migration (PR #344: assetmaint, ecommerce, lucene, scrum) and the infrastructure work (PR #1529), every real JUnit3 integration test file that existed across framework, applications, and plugins now runs on JUnit5 Jupiter - on top of the JUnit4-to-JUnit6 upgrade for standard unit tests completed back in May (PR #1301). Together, this brings our full test estate - unit and integration, framework, applications, and plugins - onto actively maintained JUnit tooling. 6) Every migrated suite was verified via scoped and full testIntegration runs, all passing with 0 failures/errors. A small follow-up (PR #1543) also fixed the noframes test-report output so HTML report generation stays consistent. 7) On my laptop, `./gradlew testIntegration` runs faster on trunk (JUnit5-based) than on release24.09 (JUnit3-based): 86.929s vs 113.327s. `./gradlew test` shows a similar pattern: 22.638s vs 27.250s. These are single-machine numbers, not a formal benchmark, but a promising signal. 8) With this, I consider my JUnit modernization work for Apache OFBiz complete, covering everything I set out to do in the May 2026 thread: unit tests on JUnit 6, and integration tests across framework, applications, and plugins on JUnit 5 (Jupiter). Thank you, everyone for the feedback and support across my previous conversations - it helped keep this moving. PRs: https://github.com/apache/ofbiz-framework/pull/1529 https://github.com/apache/ofbiz-framework/pull/1541 https://github.com/apache/ofbiz-framework/pull/1542 https://github.com/apache/ofbiz-framework/pull/1543 https://github.com/apache/ofbiz-plugins/pull/344 As always, happy to help with any JUnit5/Jupiter-related questions or issues that come up. I will provide quick assistance. *Note:* I am working on a document for the Apache OFBiz wiki for this JUnit 3 to JUnit 5 migration. I will share the document soon. Thank you! -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Sun, Aug 2, 2026 at 12:23 PM Ashish Vijaywargiya <[email protected]> wrote: > Thank you Arun! 🙏💐 > > -- > Regards, > Ashish Vijaywargiya > > On Fri, 31 Jul 2026 at 14:47, Arun Patidar <[email protected]> wrote: > > > 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/ > > > > > > >
