Field Guide · Companion · Inside the JVM

A version-aware Mockito kit for MAS 9.1 and 9.2.

The stubs field guide covers testing Maximo from the outside, at the HTTP boundary. This is the other half: unit-testing the code that lives inside Manage — Java customisations, MBO extensions, automation-script logic — with mocked business objects that refuse to pretend 9.1 and 9.2 are the same product.

What you're actually mocking

The surface is psdi.mbo.* and friends: MboRemote, MboSetRemote, MboValue, the static MXServer.getMXServer() entry point, and the MXException family. The toolchain is JUnit 5 plus Mockito 5 — the inline mock-maker is built in, which is what makes mockStatic(MXServer.class) work without ceremony. Compile each profile against the Manage development JARs of its own release: a 9.1 test compiled against 9.2 JARs hides exactly the signature drift you built the kit to catch.

One core, two version profiles

A single kit, two release profiles. Shared behaviour lives once; what genuinely differs between MAS 9.1 and 9.2 is expressed as a profile rather than a branch scattered through the tests.

Fluent builders over raw Mockito

Hand-wiring when(...).thenReturn(...) across an MboSet graph is where these suites usually die. The builders hand you a work order, an asset or a set with the field values your case needs, and nothing else.

Evidence as an annotation, enforced by the runner

Each fixture carries the release lines it is proven for. Ask for a version the evidence does not cover and the runner fails the test rather than returning a plausible value — the same rule the rest of Assetize runs on.

Where the JARs come from, and automation scripts

The JARs come from your own Manage development install, per release. Automation scripts ride the same mocks: a launch point script is a plain function of its implicit variables, so stub mbo and the script runs on your laptop in under a second.