Field Guide · Integration Testing

Stop queueing for the QA Maximo. Build a version-aware stub.

Every Maximo team knows the ritual: one shared test instance, a booking spreadsheet, and a nightly suite that fails for reasons nobody can reproduce by morning. There is a better way, and it is older than Maximo itself — the humble stub, done properly.

Why the live instance is the slowest test tool you own

A stub is a locally controlled stand-in for a remote system that answers with pre-determined responses. It is not a mock (which verifies interactions), and it is not a fake (which re-implements behaviour). It just answers — instantly, identically, every time. That modesty is the whole trick.

Against a live Maximo, a test round-trip costs seconds and the answer depends on data state, patch level, current load, and whoever else is testing that morning. Against a stub it costs milliseconds and depends on nothing. A red test means your code changed, not that someone reloaded the work order table mid-run. Flaky-test triage — the least rewarding hour in software — mostly disappears.

The compounding effects are what convince teams. Suites that ran nightly start running on every save. Developers stop serialising on one QA seat and run the full integration surface offline, in parallel, in CI. The failure paths that actually page you at 2 am — expired sessions, HTTP 429s, integration framework rejections, malformed payloads — become fixtures you serve on demand instead of incidents you wait to observe. And the metered costs of a provisioned instance simply stop accruing to testing.

The part everyone skips: version awareness

A stub that just returns what you told it to return is a machine for confirming your own assumptions. The fixtures here are derived from evidence and tagged with the release lines they are actually proven for. Ask one for a version it has no evidence for and it does the unfashionable thing: it fails, instead of guessing. Which means the suite you write today still tells you something true when you move to 9.2 — the behaviour changed under you, and here are the scripts that care.

The three-layer method

Base Maximo behaviour, a client overlay for local customisation, and the transports on top — REST, OSLC, MIF and SOAP — so a test exercises the same boundary your integration actually crosses.

One fixture store, every testing tool

The same evidence-derived fixtures drive the HTTP-boundary stub and the in-JVM Mockito kit, so the two halves of a Maximo test suite cannot drift apart.

The stub, built and downloadable

Read the companion pages: build and run a stub live in a browser terminal, the version-aware Mockito kit for MAS 9.1 and 9.2, and MXINTOBJECT and the Maximo metadata APIs that generate the fixtures.