Testing Groovy scripts

SAP's guideline is explicit: don't deploy and run integration flows to test scripts. Test them before deployment, with a simulation or in an external development environment. For Contoso that matters more than usual: every Groovy rewrite of a PO Java UDF needs proof that it behaves like the original, and the proof has to be repeatable when the script changes or Groovy is upgraded.

Three levels of script testing

A local test harness

Set up a Groovy project in your IDE and add SAP's script API from Maven Central: com.sap.cloud.script:script.api for version 1 scripts or com.sap.cloud.script:script.v2.api for version 2. That gives you the Message type and code completion. The API defines the interface, not a runtime, so you supply a small stub message. Groovy's map coercion is enough: def props = [:]
def msg = [getBody: { Class t -> t == Reader ? new StringReader(body) : body }, getProperty: { n -> props[n] }, setProperty: { n, v -> props[n] = v }] as Message
Returning a StringReader when the script asks for a Reader matters: XmlSlurper.parse given a plain String would treat it as a file name or URI.

Then load the script with a binding that supplies messageLogFactory, call it and assert: def binding = new Binding([messageLogFactory: new Expando(getMessageLog: { m -> null })])
def script = new GroovyShell(binding).parse(new File('SetPoProperties.groovy'))
script.processData(msg)
assert props.poNumber == '4500000187'
The stub log returns null, which your script already handles with a null check.

What to test

Static checks before any run

Static checks are the cheapest test you have. In the tenant, the script editor's Problems view runs the Upgrade Readiness Check and the General Script Check every time you open a script. Outside the tenant, SAP names CodeNarc 3.4.0 for analyzing Groovy code for defects, bad practices and style issues. Contoso runs it in the same build that runs the unit tests, with a short rule set agreed by Theo's team: unused imports, unused variables, empty catch blocks and string concatenation in loops fail the build. Style rules that only matter to taste are warnings, so the build stays trusted.

Where the tests live

A test that only exists on one developer's laptop isn't evidence. Contoso keeps each script, its test class and its sample payloads together in source control, with the payloads anonymized: no real bank details or contact names from XP1 traffic. The test run's output goes into the test case for the interface in SAP Cloud ALM, next to the mapping evidence from sap-pim-201. When Groovy or the script API changes version, the whole set runs again, and the results are compared before anyone touches production.

Simulation in the tenant

The integration flow simulation supports the Script step, among other message transformers. Its limit: HTTP calls made inside a script can't be simulated. Mock receiver responses on Request Reply steps instead. Simulation is the right place to check how the script interacts with the headers and properties set by earlier steps, which a local test only approximates.