Thank you, Arun! 👍🙏 Hello Dev Members,
Here comes the next work from my side on this thread - "Migrate from JMockit to Mockito" My PR: https://github.com/apache/ofbiz-framework/pull/1598 1) Test port. Ported the last 4 files in trunk still using JMockit over to Mockito: WidgetWorkerTest, RenderableFtlFormElementsBuilderDatetimeTest, RenderableFtlFormElementsBuilderTest, and MacroFormRendererTest. 2) Dependency cleanup. Dropped the JMockit dependency and its -javaagent JVM arg from build.gradle and dependencies.gradle now that nothing imports mockit.* anymore. 3) Careful semantics, not a blind find-replace. The port reproduces JMockit's auto-cascading defaults with RETURNS_DEEP_STUBS or explicit stubs where needed, and uses mockStatic(..., CALLS_REAL_METHODS) so static mocks keep faking only the intended method. 4) One real behavioral fix. Mockito's ArgumentCaptor accumulates across a mock's whole lifetime instead of per-verification-block like JMockit did; assertAndGetMacroString now uses atLeastOnce() and reads the last captured value to account for that. 5) Verification. All four ported test classes pass locally with 0 failures/errors, and a repo-wide check confirms no other file in trunk still imports mockit.*, so removing the dependency is safe. 6) Agent-loading friction. JMockit needs a -javaagent at JVM startup for its bytecode instrumentation, and the JDK has been tightening dynamic/implicit agent loading (JEP 451), which is exactly the kind of thing that quietly breaks a build on the next JDK bump. 7) One mocking framework instead of two. Mockito was already used everywhere else in the codebase; these 4 files were the last holdouts on JMockit, so consolidating removes a second API surface and one more dependency to keep compatible with each JDK upgrade. 8) JMockit's DSL doesn't fit JUnit5 well. Its @Mocked/@Injectable/@Tested and Expectations/Verifications blocks are a pre-JUnit5, reflection-heavy model, while Mockito's mockStatic()/MockedStatic composes naturally with plain @BeforeEach/@AfterEach and needs no special runner or extension. 9) Maintenance trajectory. Mockito has continuous releases and by far the larger contributor base; JMockit's release cadence has been much slower for a long time. For a project doing a JUnit5 migration explicitly to modernize its test infrastructure, betting the mocking layer on the less-maintained library works against the goal. JMockit -> https://github.com/jmockit/jmockit1/commits/master/ Mockito -> https://github.com/mockito/mockito/commits/main/ -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Fri, Aug 7, 2026 at 5:39 PM Arun Patidar <[email protected]> wrote: > Hi Ashish, > > This is an awesome contribution. I especially appreciate the addition of > the new UI for viewing the test report. > > Regards, > Arun Patidar > > > On Fri, 7 Aug 2026 at 12:54, Ashish Vijaywargiya < > [email protected]> wrote: > >> Hello Dev Members, >> >> I have added a modern new UI for the JUnit Integration Test Results in >> the Apache OFBiz project. Hopefully, you will like it as much as I do! 🙂 >> >> Please take a look at the new JUnit Reports UI here: >> >> https://drive.google.com/drive/folders/1Mcg83h07TxpHHluCZ0V0QM9dTtQA_D2a?usp=drive_link >> >> The Ant-based old JUnit Test Reports will be there as is for some time >> in the OFBiz project. >> I will be deleting the old test reports format in the upcoming days. >> >> PR: https://github.com/apache/ofbiz-framework/pull/1584 >> >> The following points are covered in this commit/push. >> >> Add modern JUnit5 test reports (single-page and framed) and fix a testdef >> suite-name casing mismatch(just following the naming convention in one test >> suite name) >> >> 1. Add a createModernTestReport Gradle task that runs alongside the >> existing createTestReports (Ant-style) task >> >> 2. Parse the JUnit suite XML output into structured data shared by both >> new report renderers >> >> 3. Render a single filterable HTML page summarizing all suites and their >> test cases >> >> 4. Extract shared summary/detail rendering and add a URL-safe suite slug >> for reuse across report pages >> >> 5. Add a navigable framed report (suite list plus per-suite detail pages) >> alongside the single-page and Ant reports >> >> 6. Clear the framed report output directory before each run so stale >> suite-*.html pages cannot linger from earlier runs >> >> 7. Add per-suite summary cards >> (tests/failures/errors/skipped/time/timestamp/host) to both new reports, >> matching the classic report's per-class summary >> >> 8. Purge stale suite XML before each test run so reports never blend >> results from an earlier run with the current one >> >> 9. Share CSS/JS across the framed report's pages via >> junit-report.css/junit-report.js instead of duplicating them on every page >> >> 10. Escape suite names before writing them into the framed report's >> title/heading >> >> 11. Sort suites by their reported name instead of by filename, and guard >> the summary totals against an empty suite list >> >> 12. Lowercase MinilangTests' suite-name/case-name for consistency with >> the naming used by the other test suites, and rename the testdef file to >> match >> >> 13. Extract the modern/framed test report tasks and their helpers out of >> build.gradle into test-reports.gradle, applied from build.gradle so it >> still runs on every Gradle invocation >> >> -- >> Kind Regards, >> Ashish Vijaywargiya >> Vice President of Operations >> *HotWax Systems* >> *Enterprise open source experts* >> http://www.hotwaxsystems.com >> >> >> >> On Mon, Aug 3, 2026 at 12:14 PM Ashish Vijaywargiya < >> [email protected]> wrote: >> >>> 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/ >>>> > > >>>> > >>>> >>>>
