Automation Script Test Harness · Documentation

What the harness checks today, and what is next.

What a script is. What runs it. What a result contains. How it stays reproducible. Built and planned work stay separate throughout — the same rule MXH's own documentation runs on.

Before you start: which one are you?

Everything below applies to both, but they are not the same run. Writing or fixing one script, day to day — use one lens, the release you actually build against (--lens mas92). Gatekeeping the fleet as DevOps — use every lens the org supports, as a CI gate. Neither one needs the other's scope. See the two use cases on the harness page and the operations page for the DevOps side in full.

What you provide

One launch point script — Jython or JavaScript — and the Maximo/MAS release lines you want it checked against. A site-specific dictionary is only needed if your script touches a custom attribute, captured the same way maximo-stub capture does. No business data, ever.

What a run checks

The script runs against a mocked Mbo/MboSet for each named lens, with mbo, mboset and service bound the way Manage injects them — real value storage, real iteration, real service.error() propagation, and a fail-closed dictionary. That catches what code review cannot: a script that will not load on the target release — a removed attribute, a changed method signature — and a script that loads but behaves differently because a domain, a default, or a field it depends on differs across releases.

What a result contains

Run status per lens — PASS, FAIL, or SKIPPED (not evidenced for this lens), never silently passed. Every difference then gets one of MXH's three grades, BLOCKING, REVIEW or ENVIRONMENT, and a lens with no evidence is stated as NOT ASSESSED, which is coverage, not a grade. The same severity names, but backed here by a mocked script execution, not by MXH's compiled-class read: different evidence for the same grade. PASS or FAIL means the script actually ran against that lens's mocked dictionary; SKIPPED means the lens has no evidence for an attribute the script touches, so no run happened and none is claimed. See how MXH's own evidence classes work for the upgrade-diff case, a different kind of evidence than this page's.

Reproducing a result

Built today: the same script against the same dictionaries produces the same result, and the execution summaries are generated, not hand-written. Roadmap: a signed lock file per run — inputs, dictionary versions, rerun id — mirroring mxh.lock.json.

The three ways to run it

CLI — built today: node bin/asz-harness.mjs script.js --lens mas91,mas92, one command and one graded verdict, zero dependencies; mvn verify -P mas91 / -P mas92 remains the full JUnit run (Jython included), and maximo-stub for the wire side. UI — built today: the terminal at /test-stubs/build, and a paste-a-script-get-a-verdict runner at /test-stubs/automation-scripts — JavaScript only, executes in the tab. API — static half built today: test_automation_script_evidence at /connect checks attribute evidence; it does not execute the script.

Install and run it — Windows, macOS, Linux

bin/asz-harness.mjs is plain Node — no compiler, no native module, no platform build. git clone https://github.com/softwarecomparereview/Assetize.git, then cd Assetize/lib/automation-script-core and node bin/asz-harness.mjs path/to/script.js --lens mas92 — the same command on macOS/Linux bash and Windows PowerShell, only the path separator differs. Requires Node 18+ and a checkout of this repository, the same requirement mvn verify already has. No published package yet — no npx, no Homebrew tap, no standalone binary; that is the honest next step, roadmap not shipped. For the fastest local feedback, point it at one lens — the release you are actually building against — with --lens mas92; add the rest once the script is ready, or leave --lens off for all five.

In your pipeline

Exit code 1 on any BLOCKING lens, 0 otherwise. GitHub Actions: actions/setup-node@v4 then node lib/automation-script-core/bin/asz-harness.mjs scripts/wo_costcentre.js --lens mas91,mas92. Azure DevOps: NodeTool@0 then the same command as a script step. Jenkins (declarative): the same command in an sh step inside a stage. Same three stages named on the operations page: build time runs it against one lens on a laptop, pre-merge runs it in the pipeline and gates on the exit code, deploy time reruns it against the target environment's own lens.