Skip to main content
Two FireWeave-provided tools mean unit and most integration tests never need a backend account:
  1. InMemoryAdapter — fixture-driven BackendAdapter in every language. Bind the real runtime (and, if you want, the real OpenFeature client) to it.
  2. The protocol test server (test-server/) — zero-dependency Node HTTP stub with scriptable faults. Use it when you need the real HTTP path of FireweaveRemoteAdapter.
A third option on Node, Python, and Web only: FireweaveLocalAdapter (web: FireweaveLocalWebAdapter) for a boolean devFlags map.
The test server does not implement POST /v1/targets/register. The SDK’s own docs/testing.md claims it does; that is wrong relative to test-server/implementation/server.mjs. Register-target tests in the SDK use mocks or injected fetch, not this stub. InMemoryAdapter also does not persist registration (UnsupportedCapability).

InMemoryAdapter

Same conceptual fixture in every language: type, enabled, value, optional variant, payload, metadata, and optional match conditions that gate on context attributes (no match → your default). Java: artifact ai.fireweave:fireweave-testing (<scope>test</scope>). Web: InMemoryWebAdapter.
Adapted from the SDK testing doc (OpenFeature + lazyReady: false):
Node extras: fault: { kind: 'Timeout' } fails every resolve with that kind; initError: 'Configuration' fails initialize() (runtime → FATAL); initGate holds init open; setFlags() / setFault() mutate live.
cohort: 'beta' in these snippets is an example attribute name, not an SDK type. See Targeting.

Local / dev adapter

Node, Python, and Web only. Go and Java have no local adapter on master. Resolution: Reading a devFlags key as a string or number is TYPE_MISMATCH. devFlags is Record<string, boolean>.
Python: make_fireweave_local_provider(), get_fw_local_captures(), reset_fw_local_captures(). Web: FireweaveLocalWebAdapter behind FireweaveWebRuntime.
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.

Protocol test server

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

Routes that exist

FireWeave-native (test-server/implementation/server.mjs and PATHS.md): Vendor (PostHog) routes, for languages that still ship a vendor adapter: Not implemented: POST /v1/targets/register. 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 FLAG_NOT_FOUND → default unless you replace fixtures.
Go harness env: FIREWEAVE_TEST_SERVER_URL or FW_TEST_SERVER_URL.

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 → default + FLAG_NOT_FOUND (never a throw).
  • Type mismatch → default + TYPE_MISMATCH.
  • Missing targetingKey with requireTargetingKey → default + TARGETING_KEY_MISSING.
  • Before init / after shutdown → default + PROVIDER_NOT_READY (NotReady vs AlreadyClosed in fireweave.errorKind).
  • Exposures: sendExposure default false; explicit record + flush; dedup on (targetingKey, flagKey, variant, value).
  • Do not assert target registration against InMemory or the test-server stub.

CI

Cross-language fixtures live in contracts/ (65 shared; web has 10 in contracts/web/). Runners per language; CI job differential compares reports. That suite is for SDK contributors — application tests should use InMemoryAdapter (or the stub for HTTP).

Next

Adapters

InMemory vs remote vs local vs PostHog extras

Troubleshooting

Defaults, fixtures, and install mismatches
Last modified on August 18, 2026