Skip to main content
@faremeter/test-harness provides an in-process test environment that connects client, middleware, and facilitator using function adapters instead of HTTP. No real blockchain interaction, no network calls, no running servers.

TestHarness

The TestHarness class wires together a client, middleware, and facilitator in memory. It creates a fetch function that runs the full x402 payment flow — 402 response, payment construction, settlement — entirely in-process.

Configuration

Resource handler

Set a custom response for the protected resource:

Reset

Call harness.reset() between tests to clear interceptors and restore defaults.

Test helpers

The accepts() and acceptsV2() helpers create payment requirements with sensible test defaults so you don’t need to specify every field:

Interceptors

Interceptors wrap the fetch pipeline to observe, modify, or block requests. They sit between the client and middleware, or between middleware and facilitator.

Logging

Capture all requests and responses for inspection:
Or log to the console during debugging:

Capturing requests

Inspect specific requests matching a pattern:

Simulating failures

Test error handling by making specific requests fail:

Simulating latency

Composing interceptors

Combine multiple interceptors into one:

Request matchers

Matchers are predicate functions that determine which requests an interceptor acts on: Combine matchers with and(), or(), and not():

Payer choosers

When multiple payment options are available, the payer chooser selects which one to use. The test harness provides choosers for testing different selection strategies: Wrap choosers with additional behavior:

Test handlers

For testing specific facilitator behaviors, use the pre-built handler factories:

Example: full test

Further reading