@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
TheTestHarness 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
| Option | Type | Description |
|---|---|---|
accepts | x402PaymentRequirements[] | Payment requirements the test server returns. Use the accepts() helper for defaults. |
clientHandlers | PaymentHandlerV1[] | Required. Client-side payment handlers (v1, internally adapted to v2). Use createTestPaymentHandler() for tests. |
facilitatorHandlers | FacilitatorHandler[] | Required. Facilitator handlers. Use createTestFacilitatorHandler({ payTo }) for tests. |
clientInterceptors | Interceptor[] | Interceptors between client and middleware. |
middlewareInterceptors | Interceptor[] | Interceptors between middleware and facilitator. |
settleMode | "settle-only" | "verify-then-settle" | Whether to verify before settling. Default: "settle-only". |
Resource handler
Set a custom response for the protected resource:Reset
Callharness.reset() between tests to clear interceptors and restore defaults.
Test helpers
Theaccepts() 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: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:| Matcher | Matches |
|---|---|
matchAll | Every request |
matchNone | No requests |
matchFacilitator | Any facilitator endpoint |
matchFacilitatorAccepts | POST /accepts |
matchFacilitatorSettle | POST /settle |
matchFacilitatorVerify | POST /verify |
matchFacilitatorSupported | GET /supported |
matchResource | The protected resource request |
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:| Chooser | Behavior |
|---|---|
chooseFirst | Picks the first available option |
chooseCheapest | Picks the lowest amount |
chooseMostExpensive | Picks the highest amount |
chooseByScheme(scheme) | Returns a chooser that matches by payment scheme |
chooseByNetwork(network) | Returns a chooser that matches by network name |
chooseByAsset(asset) | Returns a chooser that matches by asset name |
chooseByIndex(n) | Returns a chooser that picks by array index |
chooseNone | Always throws — tests “no option” paths |
Test handlers
For testing specific facilitator behaviors, use the pre-built handler factories:| Factory | Behavior |
|---|---|
createTestPaymentHandler() | Standard test handler (no crypto) |
createTestFacilitatorHandler({ payTo }) | Standard facilitator handler (no crypto). payTo is required. |
createWorkingHandler() | Always succeeds |
createNonMatchingHandler() | Returns no matching execers |
createThrowingHandler(message) | Always throws with the given message |
createEmptyPayloadHandler() | Returns empty payload |
createNullPayloadHandler() | Returns null payload |
Example: full test
Further reading
- Test Harness API Reference — Complete API documentation.
- Middleware Overview — How server-side middleware works.
- Payment Handlers — The handler interface used by the test harness.