# Test the promise at the boundary

Choose checks that establish meaningful behavior, including denied effects and real consumer imports.

Source context: Source-guided
Source: https://github.com/lssm-tech/contractspec/blob/d58fa5b7de53a947811e5cc68346be028ce18528/packages/foundation/contracts-runtime-kernel/src/operations/registry.ts

## Give each test one question

An operation has several boundaries, and one green check cannot answer every question about them. Separate declaration validity, business behavior, adapter behavior and external consumption so failures tell you where to look.

For a first integration, keep the matrix small. Choose the success case your tutorial promises and the failure that demonstrates its most important protection.

| Check | Question it answers | Useful assertion |
| --- | --- | --- |
| Contract/schema | Does the declared shape behave as intended? | Required values accepted or rejected |
| Handler | Does the business rule hold? | Expected state transition and outcome |
| Registry | Does configured execution enforce the boundary? | Denied request leaves handler count at zero |
| Transport | Does the actual API/tool expose it correctly? | Wire result and context mapping |
| Consumer | Can users install and import this version? | Clean external project succeeds |

## Test denied effects explicitly

Use a handler with a visible disposable effect, such as a local counter or fake outbox. Supply otherwise valid input so the request reaches the guard you are testing. Missing approval should leave that effect untouched.

Invoke the adapter used by your users, not only a private helper. For an API-plus-MCP claim, exercise both real entry points and inspect their canonical failure information.

## Test the risks of your implementation

A schema can validate input while a handler still produces the wrong state. Add tests for business invariants, resource ownership and the failure paths of any provider you bind. Verify idempotency or retry behavior where your application depends on it.

An invalid output is detected after handler execution. If an effect must be atomic with a record of the result, test the host's transaction or outbox implementation rather than assuming output validation supplies rollback.

## Report the scope of the result

Repository tests use the repository's dependency graph. Packed-artifact checks test built tarballs. An anonymous registry consumer verifies that an external user can fetch and execute the published version. Keep these results separate.

For documentation, record the source or package version and exact scenario. A metadata smoke test is useful for an example catalogue, but it should not be described as a successful end-to-end workflow.

## Related examples

- [Stop a write before it runs](https://lssm.co/examples/required-approval/): Trace a REST request through an approval gate and inspect the zero-handler-call denial assertion.
- [Capture now, complete when ready](https://lssm.co/examples/form-showcase/): Use form contracts to accept a minimal intake while keeping missing readiness fields visible.