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