Thank you, Chandan & Pranay!! 🙏👍 -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com
On Mon, Aug 31, 2026 at 3:29 PM Chandan Khandelwal < [email protected]> wrote: > Hello Ashish, > > Thanks for sharing this. I think these changes can be quite useful for our > regular OFBiz testing, specially when we need to run tests remotely and > validate changes quickly. > > The ability to pass different test parameters should make it easier to test > different scenarios without changing the test code each time. The batch > execution can also help when we need to run a larger set of tests across > different components. > > I will spend some time trying these features with real test cases and see > how they fit into our current testing and deployment process. I will share > more feedback and inputs once I have tested them. > Kind Regards, > Chandan Khandelwal > > > > On Mon, Aug 24, 2026 at 6:17 PM Pranay Pandey <[email protected]> > wrote: > > > Hi Ashish, > > > > Thank you for sharing this comprehensive summary of the testing framework > > enhancements. The improved test support will have a significant impact. > > > > Best regards, > > Pranay Pandey > > > > > > > > > > > > On Mon, 24 Aug 2026 at 11:50, Ashish Vijaywargiya < > > [email protected]> wrote: > > > > > Dear OFBiz Dev Members, > > > > > > Sharing a summary of the testing framework work I completed in the last > > few > > > days, organised feature by feature below, along with the pull request > for > > > each one. > > > > > > *1. REST API Support to Run JUnit and Integration Test Cases* > > > > > > This feature lets JUnit and Integration test cases be triggered and > > polled > > > over a simple REST call instead of requiring direct server access and a > > > hand typed command, so tools like Postman or any CI dashboard can > start a > > > test suite and check its status the same way they would call any other > > web > > > service. The existing Gradle based way of running test cases is > untouched > > > and continues to work exactly as before, so this is purely an > additional > > > way in, not a replacement. This is a meaningful step for the project > > > because it opens the door to automated, remote, and scheduled test > > > execution, which is something a command line only workflow could never > > > offer, and it means test runs can now be wired directly into CI > pipelines > > > and dashboards without anyone needing shell access to an OFBiz server. > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1690 > > > PR: https://github.com/apache/ofbiz-framework/pull/1699 > > > > > > *2. History of Test Case Reports* > > > > > > This feature retains test case reports across runs in the runtime and > > build > > > folders instead of letting each run overwrite the previous one, so a > > record > > > of past results is available to look back on. This is valuable for the > > > project because a single run only tells us pass or fail for that > moment, > > > while a retained history lets us analyse trends over time, such as > > noticing > > > that a particular test case has been getting slower over the last week, > > or > > > that a certain suite has started failing intermittently, which is > exactly > > > the kind of signal that is impossible to see from a single report > alone. > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1681 > > > > > > *3. testParams Map Support in Test Cases* > > > > > > This feature lets a caller pass a testParams map of additional values > > into > > > a test run from Postman or any other application, instead of the test > > case > > > being limited to whatever values are hardcoded inside it. Below is a > > sample > > > curl call showing this in action, followed by the OFBiz test case code > > that > > > reads the testParams map and falls back to its previous hardcoded > > defaults > > > whenever a given parameter is not supplied. > > > > > > -- Trigger a run (optionally scope to one test case / test method), > then > > > poll for the result > > > > > > POST https://localhost:8443/rest/testtools/testruns/{componentName} > > > (body: the JSON below) > > > GET https://localhost:8443/rest/testtools/testruns/{runId} > > > (poll for status/result) > > > > > > curl -sk -X POST > > https://localhost:8443/rest/testtools/testruns/example > > > \ > > > -H "Authorization: Bearer <token>" -H "Content-Type: > > application/json" > > > \ > > > -d '{ > > > "suiteName": "example-tests", > > > "testCaseName": "example-tests-jupiter", > > > "testMethodName": "shouldCreateExample", > > > "testParams": { "exampleTypeId": "INSPIRED" } > > > }' > > > > > > curl -sk https://localhost:8443/rest/testtools/testruns/<runId> \ > > > -H "Authorization: Bearer <token>" > > > > > > @Test > > > @Order(1) > > > void shouldCreateExample() { > > > > > > GenericValue userLogin = delegator.findOne('UserLogin', > > > [userLoginId: 'system'], false) > > > > > > String exampleTypeId = testParams.exampleTypeId ?: 'CONTRIVED' > > > String exampleName = testParams.exampleName ?: 'Test Example - > > > Integration' > > > String statusId = testParams.statusId ?: 'EXST_IN_DESIGN' > > > > > > Map<String, Object> result = > dispatcher.runSync('createExample', > > [ > > > exampleTypeId: exampleTypeId, > > > exampleName: exampleName, > > > statusId: statusId, > > > userLogin: userLogin > > > ]) > > > assert ServiceUtil.isSuccess(result) > > > > > > GenericValue example = from('Example').where('exampleId', > > > result.exampleId).queryOne() > > > assert example != null > > > Assertions.assertEquals(exampleTypeId, example.exampleTypeId) > > > Assertions.assertEquals(exampleName, example.exampleName) > > > Assertions.assertEquals(statusId, example.statusId) > > > } > > > > > > Currently, all the integration test cases in OFBiz contain hardcoded > > > values, so this feature is useful as the number of test cases that read > > > from testParams. This is beneficial for the project because it turns > > every > > > migrated test case into a reusable, parameterised check rather than a > > > single fixed scenario, so the same test can be driven with different > > inputs > > > from Postman or a CI tool without anyone touching the test source, and > > the > > > remaining integration test cases across OFBiz can now be migrated the > > same > > > way over time. > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1700 > > > > > > *4. Component Based Enable/Disable Support for the Test Run REST API* > > > > > > This feature lets the REST API for running test cases be enabled or > > > disabled on a per component basis, using the SystemProperty entity to > > store > > > the setting, so an OFBiz restart is no longer required whenever this > > needs > > > to change. This matters for the project because it gives administrators > > > fine grained control over exactly which components expose test > execution > > > over REST, without forcing an all or nothing global switch and without > > any > > > server downtime just to flip that switch, which makes the feature far > > more > > > practical to use safely in a shared or production like environment. > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1698 > > > PR: https://github.com/apache/ofbiz-plugins/pull/373 > > > > > > *5. Batch Test Run REST API* > > > > > > This feature adds a batch endpoint on top of the existing test run REST > > > API, so a single call can fan a full test suite run out across multiple > > > components at once and track the whole batch under one batchId, instead > > of > > > a caller having to trigger and poll each component one at a time. This > is > > > beneficial for the project because it makes it practical to kick off a > > full > > > regression pass across many or even all components with one request and > > one > > > identifier to poll, which is exactly the kind of bulk operation a CI > > > dashboard or a nightly build pipeline needs. > > > > > > -- Trigger a batch run across components, then poll for the aggregate > > > result > > > > > > POST https://localhost:8443/rest/testtools/testruns/batch > > > (body: > > > the JSON below) > > > GET https://localhost:8443/rest/testtools/testruns/batch/{batchId} > > > (poll for status/result) > > > > > > curl -sk -X POST > https://localhost:8443/rest/testtools/testruns/batch > > \ > > > -H "Authorization: Bearer <token>" -H "Content-Type: > > application/json" > > > \ > > > -d '{ "components": ["example", "party","order"] }' > > > > > > curl -sk https://localhost:8443/rest/testtools/testruns/batch/ > > <batchId> > > > \ > > > -H "Authorization: Bearer <token>" > > > > > > Leaving out the components list altogether queues every component that > > has > > > a testdef and has the test execution API enabled, so a caller can > > trigger a > > > full regression across the whole project without naming a single > > component > > > by hand. > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1701 > > > > > > I am hopeful that these features will be useful to the Apache OFBiz > > > project. > > > Thank you! > > > > > > -- > > > Kind Regards, > > > Ashish Vijaywargiya > > > Vice President of Operations > > > *HotWax Systems* > > > *Enterprise open source experts* > > > http://www.hotwaxsystems.com > > > > > >
