Automation Script Test Harness · Built from mockkit + the test stub

Test one Automation Script against every Maximo release it might run on.

Give it a launch point script — Object, Attribute, Action or Cron Task — and the harness runs it against a mocked Mbo for each release you name, then says plainly which ones it passes, which it breaks, and which it has never been checked against.

Two ways to use this. You do not need every version for either one.

The multi-lens table further down is the harness proving itself, not the only way to run it. Most runs — most days — are one script against one version. Day to day, one developer, one version: writing or fixing a script right now, point the harness at your one release — node bin/asz-harness.mjs script.js --lens mas92 — and run it before you commit, the same way you'd run a unit test. Fleet-wide, DevOps, every version: once a script is delivered, run the same harness against every release the org supports — node bin/asz-harness.mjs script.js --lens 761,mas811,mas90,mas91,mas92, or drop --lens for all five — as a CI gate catching a regression the author never tested. Same engine either way, not two tools. See the operations page.

What it tests

Object launch point — fires on save: add, update, delete. Fires from the UI, from the MIF, and from REST/OSLC. Not only the UI. Attribute launch point — fires on initialize and validate, for one attribute. Action and Sig Option — fires when invoked. Cron task and escalation — fires on schedule, no user in the loop. One script. One lens list. No customisation dictionary export.

See it graded

Two real Object launch point scripts from the kit (wo_costcentre.py, wo_costcentre.js) run across the MAS 9.1 and MAS 9.2 profiles. ZZ_SHIFT exists on MAS 9.2 and not on MAS 9.1: the same suite passes on 9.2 and is skipped — not silently passed — on 9.1. A third script, wo_shift_unconditional.js, is written to fail: it reads ZZ_SHIFT with no isNull() guard, so it blocks on both lenses — missing-attribute on 9.1, service.error() on 9.2. A results table that never shows a failure is not evidence of a working harness, only of scripts chosen to pass.

How a result is graded

Pass, fail, skip tells you what happened. Every difference gets one of the three grades MXH gives a full upgrade diff: BLOCKING, REVIEW or ENVIRONMENT. It's the same fact whether it is one script or your whole customisation set. A lens with no evidence is stated as NOT ASSESSED, which records what wasn't checked and isn't a fourth grade. This harness's own evidence is a mocked script execution — a script actually ran against a fake Mbo/MboSet and either raised service.error(), threw, or completed — a different kind of evidence from MXH's, which grades a diff read from IBM's own compiled classes. The harness reuses MXH's grade names because they mean the same severity either way, not MXH's evidence classes, which describe confidence in a compiled-class read, not in a script run.

Three ways in: CLI, UI, API

One engine decides what a run means; CLI, UI and API are thin clients over it, the same split the test stub's own engine uses. CLI, today: node bin/asz-harness.mjs script.js --lens mas91,mas92 — one command, one graded verdict; mvn verify -P mas91 / -P mas92 remains the full JUnit run (Jython included), maximo-stub for the wire side. UI, today: a whole version-aware Maximo live in a browser terminal at /test-stubs/build, and a paste-a-script-get-a-verdict runner on this page — JavaScript executes against a mocked Mbo in the tab, nothing sent anywhere. API, static half today: test_automation_script_evidence at /connect checks a script's referenced attributes against a lens dictionary — no UI, no prompts, no execution, because Workers cannot safely run arbitrary code server-side.

What ships separately

No system export. No customisation dictionary. No MXH-sized engagement. One script, checked against the releases you name. Talk to us about the harness.