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 >
