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/ >>> > > >>> > >>> >>>
