Tests & observability
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
Verify promises at each boundary
Section titled “Verify promises at each boundary”A useful integration test proves a contract: the input accepted, the remote calls made, the state changed, and the result reported. Checking only that a flow returned success can miss an incorrect side effect.
The Runtime test harness and observability interfaces are not published. This page describes a general strategy rather than available testing commands.
Use layers of evidence
Section titled “Use layers of evidence”- Pure mapping tests: deterministic fixtures, required fields, type handling, and edge values.
- Connector contract tests: timeouts, authentication, headers, redirects, response decoding, and cancellation.
- Integration scenarios: correct ordering, duplicate handling, partial success, and terminal failure.
- Operational exercises: resource limits, degraded dependencies, and recoverable deployment failure.
Design observations alongside behavior
Section titled “Design observations alongside behavior”Record enough information to connect related work: a safe correlation identifier, the boundary name, elapsed time, and outcome category. Decide who can access those signals and how long they are retained. Payload logging should be reviewed separately, with redaction rules tested.
No telemetry backend, tracing format, monitoring exporter, or metric name is promised for Runtime here.
A scenario worth writing down
Section titled “A scenario worth writing down”An inventory write succeeds but its response is lost. The caller retries. The test should establish whether one inventory update occurs, how a duplicate is recognized, and what result the caller receives. If the system cannot establish an outcome, its contract should say so.
Use errors and retries to define that scenario before selecting a test mechanism.