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
