External-system provider simulators

provider-simulators stands in for the external target systems an application reads from and writes to. Seven faces are implemented: Odoo’s remote-procedure endpoint, an OData version-four endpoint, a version-two endpoint in the flavour SAP S/4HANA publishes, a route-driven generic HTTP double for provider operations and record APIs, two statement-reading doubles for Salesforce’s SOQL and NetSuite’s SuiteQL, and an OAuth 2.0 token endpoint a system of record’s service identity authenticates against. Each is a standalone server started from one orchestrator, with no framework imports.

The problem it solves

Reading data out of somebody else’s system is mostly a question of dialect. The envelope differs, the paging property differs, the query language differs, and a wrong answer looks like an empty result rather than an error. Testing that against the real system means holding an account, a network path and a data set, none of which belongs in a test lane; testing it against a stub written from the same assumptions as the reader proves only that the assumptions are self-consistent.

The version-two case is the clearest illustration. The engine’s OData reader expects a value array and a next link, which is version four. A widely used enterprise business-partner service publishes version two, whose envelope wraps everything in a different property, names its results differently and carries a different next link and count. A version-four reader pointed at it finds no array and fails on the first page. Only a double that is faithful to the published version-two format shows that, which is why the two are separate doubles rather than one with a flag.

What it does

Protocol-faithful doubles for the external systems an application reads from and writes to — Odoo’s remote-procedure envelope, two versions of a standard query protocol, two vendors’ statement-based query resources, an OAuth token endpoint, and a route-driven generic REST face.

Each face is faithful to a PUBLISHED protocol rather than to the framework, and none of them imports anything from it. That is the load-bearing property: a double derived from the reader would agree with the reader by construction, so a framework defect could never surface.

The Odoo face implements the envelope, the authenticate call including its rejection answer, and the read family with the domain query language, its prefix-notation combinators and its operator set. It also performs row writes — create, write and delete — stamping the last-updated column the way Odoo does, and two actions, including posting a draft invoice. The newer query face parses the filter grammar subset a query compiler realistically emits, by recursive descent, answers the metadata document as well as the count, and accepts create, merge-update and delete, with entity tags honoured on update and delete and a full replacement refused. The older face implements the other envelope, the other paging and the other count.

The two statement faces reproduce what defeats a naive reader: Salesforce answers a query in batches smaller than the limit, behind a locator that only sees the result as of the query; NetSuite requires its header, refuses offsets that are not a multiple of the limit and stops an offset walk at its result ceiling. The token face records every token request verbatim, so a test can tell which part of a request was wrong.

The generic double is deliberately a different shape. A provider operation has no dialect — only a method, a path template, parameters and a body encoding — so this face is route-driven: a test declares routes the way a vendor’s API reads on paper, and the double records what actually ARRIVED, including query parameters, headers and the raw body with its content type. That record is the assertion surface, and it is what turns “the parameter went to the query rather than the body” into a checkable fact rather than an inference from a successful status. It also serves two record APIs shaped like Salesforce’s and NetSuite’s, for the two ways such an API answers a create.

Two faces carry a knob that forces one throttled answer after a chosen number of calls, and the token face can throttle its first request, so transport-retry machinery has a live counterpart rather than a mocked one.

Limits

The application-level lane is not claimed by the suite. More than thirty engine test suites start these doubles and drive the engine against them over real HTTP, and one end-to-end scenario drives a running application’s read-through resource against the Odoo double. That scenario needs the application to have been started pointed at the double, so it is registered unclaimed and skips elsewhere; the claim that an application’s data pipeline works end to end against one of them has not been made by a lane.

The doubles are faithful to a scoped subset of each protocol, chosen as what a query compiler realistically emits. Constructs outside that subset are not implemented, and the source says so at each face.

They carry no business logic and no persistence. A fixture is supplied at start-up, or replaced through a test-only door outside each protocol, and kept in memory. The Odoo, OData version-four and generic record faces accept writes and change their rows the way the vendor answers them, but carry none of a real system’s business rules or permissions.