Skip to main content
Wildo.ai Coming soon

Testing harnesses

Customer-infrastructure test double

A standalone service that stands in for a customer's identity provider, directory, security-event sink and webhook receiver, so enterprise integrations can be proven end to end without a real customer.

What it is
Tool — something you run.
What it does
A running fleet standing in for the systems a customer would operate — an identity provider, a directory that pushes users in, a security-event collector, a webhook receiver — so an isolation claim is asserted from ROWS rather than inferred.
Where it stops
It carries no business logic and no application data.

The engine

End-to-end scenarios

A running stack

Customer double

Client integration double

Vendor simulators

Drawn for Testing harnesses, the area this capability belongs to.

client-org-mock impersonates the IT infrastructure of a customer organisation: an OpenID provider, a SAML identity provider, a directory-provisioning client, a security-event sink and a webhook receiver. All five mount under path prefixes on one port, so one instance is one origin, and a fleet runs one instance per tenant with its own recording database. It is the passive half of the pair: the systems an application calls out to.

The problem it solves

Every enterprise integration is a claim about what happens on the other side of a boundary you do not control. Signature validation, per-tenant routing, provisioning, security-event delivery and webhook signing all fail in ways that look identical from inside the application: a request was sent, no error was raised, and nobody knows whether the right thing arrived at the right place.

Isolation defects are worse still, because the symptom is invisible from a single tenant. One customer’s audit records arriving at another customer’s security sink produces no error anywhere; the sending tenant sees a success and the receiving tenant sees data it should never have had. That class can only be caught by watching two independent receivers at once and asserting that one of them stayed silent, which is precisely what this double makes possible.

What it does

A running fleet standing in for the systems a customer would operate — an identity provider, a directory that pushes users in, a security-event collector, a webhook receiver — so an isolation claim is asserted from ROWS rather than inferred.

Each face wraps a standard library rather than reimplementing a protocol, mirroring the framework’s own choice so the handshake is symmetric. The package owns the wiring and the recording and nothing else: no fake business objects, only a small seed so sign-on and provisioning can round-trip.

Every observation is written to a durable per-instance database, carrying the face, a sub-kind, a one-line summary and an optional idempotency key mirroring the application’s own de-duplication. A scenario reads them back over an inspection surface, which is what turns “did the assertion land” into a row count rather than a guess. Because the database is per instance, the isolation question is answered without any shared query surface: the tenant that should have received the traffic has rows and every other tenant has none.

The package sits deliberately outside the framework’s workspace, with its own lockfile, so its dependencies never touch the framework’s resolution. The one exception is the security-event receiver, whose parser is written from the published grammars rather than from the framework’s emitter — and that independence is the entire point: a receiver derived from the producer would agree with the producer by construction, and a format defect would read as agreement.

The directory face inverts the direction. Wildo is the provisioning SERVER there, so the double is the client that pushes users in.

Limits

It carries no business logic and no application data. It proves that the right protocol exchange reached the right origin; whether the application then did the right thing with it is asserted on the application side.

Two faces need the same toolchain the framework’s own assertion validation needs, including a compiled helper. When that helper is missing, the failure surfaces as an invalid signature rather than as a missing dependency — a misleading error for the person meeting it.

Its own notes state that the package imports no framework packages. That is no longer literally true: it takes a type-only import of the shared spine so the fleet satisfies the same observation contract every other surface does. Nothing of the runtime crosses the boundary, but the sentence overstates the separation.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.