Skip to main content
Two Fireweave-provided tools mean unit and most integration tests never need a backend account:
  1. mode: 'local' — seeded boolean map, no network, no credentials. registerTarget records in-process and traces.
  2. InMemoryAdapter — fixture-driven adapter in every language. Use it when you need attribute match conditions, faults, or live mutation.
A third option when you need the real HTTP path: the protocol test server (test-server/).
The test server does not implement POST /v1/targets/register. InMemoryAdapter also does not persist registration (UnsupportedCapability). Use local mode when the test must assert registration.
There is no FireweaveProvider and no makeFireweaveLocalProvider. Bind FireweaveClient (or initFireweave) to an adapter.

Local mode

Present in all seven languages. Reading a seeded key as a string or number is TypeMismatch. The map is boolean-only.
Call-site defaults stay false. Do not write getBooleanValue(key, true) to dogfood locally — that same true is the production fallback when a control point is absent.

InMemoryAdapter

Same conceptual fixture in every language: type, enabled, value, optional variant, and optional match conditions that gate on context attributes (no match → your default). Java: artifact ai.fireweave:fireweave-testing (never published; maven.deploy.skip=true). Web: InMemoryWebAdapter.
Node extras: fault: { kind: 'Timeout' } fails every resolve with that kind; initError: 'Configuration' fails initialize() (runtime → FATAL).
cohort: 'beta' in these snippets is an example attribute name, not an SDK type. See Targeting.

Protocol test server

Zero-dependency Node stub, loopback-only by default:

Routes that exist

Not implemented: POST /v1/targets/register. The stub also still serves legacy vendor routes (POST /flags?v=2, definitions poll, /batch/) for historical harnesses. No shipped SDK talks those paths. Auth on Fireweave routes: Authorization: Bearer <key>. Any non-empty key is accepted unless you configure one. Use obviously fake keys (project-api-key_dev). The stub serves its own fixture keys (fw-bool-on, and others from test-server/fixtures/flags-v2-success.json). Keys your app expects resolve FlagNotFound → default unless you replace fixtures. Point initFireweave({ mode: 'remote', apiUrl, apiKey }) at http://127.0.0.1:3901. Your application reads FW_API_URL if you want; the SDK does not.

Faults and assertions

Per-request: header X-Fw-Test-Fault: <mode> or query ?fault=<mode>.

What to assert

  • On / off / no-match → value, variant, reason.
  • Missing key on remote → default + FlagNotFound (never a throw).
  • Missing key on local → default + DEFAULT (never an error).
  • Type mismatch → default + TypeMismatch.
  • Missing targetingKey with requireTargetingKey → default + TARGETING_KEY_MISSING.
  • Before init / after shutdown → default + NotReady / AlreadyClosed.
  • Local registerTarget → { ok: true } and a readable recorded set.
  • Do not assert target registration against InMemory or the test-server stub.

CI

Cross-language fixtures live in contracts/. Surface parity is conformance/surface/control-points.surface.json. That suite is for SDK contributors — application tests should use local mode or InMemoryAdapter (or the stub for HTTP).

Next

Adapters

InMemory vs remote vs local

Troubleshooting

Defaults, fixtures, and install mismatches
Last modified on September 11, 2026