DataDog
diff --git a/‎content/en/feature_flags/client/_index.md‎
Lines changed: 18 additions & 0 deletions b/‎content/en/feature_flags/client/_index.md‎
Lines changed: 18 additions & 0 deletions
diff --git a/‎content/en/feature_flags/client/android.md‎
Lines changed: 68 additions & 0 deletions b/‎content/en/feature_flags/client/android.md‎
Lines changed: 68 additions & 0 deletions
diff --git a/‎content/en/feature_flags/client/ios.md‎
Lines changed: 173 additions & 0 deletions b/‎content/en/feature_flags/client/ios.md‎
Lines changed: 173 additions & 0 deletions
diff --git a/‎content/en/feature_flags/client/javascript.md‎
Lines changed: 44 additions & 0 deletions b/‎content/en/feature_flags/client/javascript.md‎
Lines changed: 44 additions & 0 deletions
diff --git a/‎content/en/feature_flags/client/react.md‎
Lines changed: 19 additions & 0 deletions b/‎content/en/feature_flags/client/react.md‎
Lines changed: 19 additions & 0 deletions
diff --git a/‎content/en/feature_flags/server/_index.md‎
Lines changed: 18 additions & 0 deletions b/‎content/en/feature_flags/server/_index.md‎
Lines changed: 18 additions & 0 deletions
@@ -21,6 +21,24 @@ Set up Datadog Feature Flags for your applications. Follow the platform-specific
 
 {{< partial name="feature_flags/feature_flags_client.html" >}}
 
+## Testing with in-memory providers
+
+Datadog supports these testing approaches:
+
+- **Integration tests**: Point `DatadogProvider` at a dedicated test environment and control flag values from the Datadog UI. This exercises the real provider end-to-end, including the CDN-delivered flag assignments.
+- **Unit tests**: Swap `DatadogProvider` for OpenFeature's standard `InMemoryProvider` (or an equivalent test stub, where no in-memory provider is available in the language) and set flag values directly in test code. This keeps tests hermetic and offline.
+
+This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.
+
+A typical test follows this pattern:
+
+1. Build a map of flag keys to variants in your test setup.
+2. Register an `InMemoryProvider` with that map through the OpenFeature API.
+3. Call the OpenFeature client in the units being tested. The `InMemoryProvider` returns the flag assignments configured at test setup.
+4. Reset the provider in test teardown to avoid cross-test state leakage.
+
+See your platform's SDK page (select from the top of this page) for a concrete test example.
+
 ## Context attribute requirements
 
 <div class="alert alert-warning">
 
@@ -431,9 +431,77 @@ This table highlights key differences between the OpenFeature and `FlagsClient`
 | **Vendor Lock-in** | Low (vendor-neutral) | Higher (Datadog-specific) |
 | **State Management** | Flow-based observation | Manual listener registration |
 
+## Testing
+
+You can test against a dedicated Datadog test environment with the real Datadog provider, or swap it for an in-memory `FeatureProvider` to control flag values directly in test code. This section shows the in-memory approach, which keeps tests hermetic and offline. The upstream OpenFeature Kotlin SDK does not ship an [`InMemoryProvider`][3], so tests use a small custom `FeatureProvider`. The example below replaces `OpenFeatureAPI`'s provider — if your production code uses the Datadog `FlagsClient` wrapper directly, your test should assert through the same `OpenFeatureAPI` client the wrapper uses, not `FlagsClient`.
+
+Add `kotlinx-coroutines-test` to your test configuration (the SDK's `initialize` is a `suspend` function):
+
+{{< code-block lang="groovy" filename="build.gradle" >}}
+dependencies {
+    testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.8.1'
+}
+{{< /code-block >}}
+
+{{< code-block lang="kotlin" >}}
+import dev.openfeature.kotlin.sdk.*
+import dev.openfeature.kotlin.sdk.events.OpenFeatureProviderEvents
+import kotlinx.coroutines.flow.Flow
+import kotlinx.coroutines.flow.MutableSharedFlow
+import kotlinx.coroutines.test.runTest
+import org.junit.Before
+import org.junit.Test
+import kotlin.test.assertTrue
+
+class FakeProvider(private val flags: Map<String, Any>) : FeatureProvider {
+    override val hooks = emptyList<Hook<*>>()
+    override val metadata = object : ProviderMetadata { override val name = "fake" }
+    private val events = MutableSharedFlow<OpenFeatureProviderEvents>(replay = 1)
+
+    override suspend fun initialize(initialContext: EvaluationContext?) {
+        // No-op. The SDK emits ProviderReady after initialize returns.
+    }
+    override fun shutdown() {}
+    override suspend fun onContextSet(old: EvaluationContext?, new: EvaluationContext) {}
+
+    override fun getBooleanEvaluation(key: String, defaultValue: Boolean, context: EvaluationContext?) =
+        ProviderEvaluation(value = (flags[key] as? Boolean) ?: defaultValue)
+    override fun getStringEvaluation(key: String, defaultValue: String, context: EvaluationContext?) =
+        ProviderEvaluation(value = (flags[key] as? String) ?: defaultValue)
+    override fun getIntegerEvaluation(key: String, defaultValue: Int, context: EvaluationContext?) =
+        ProviderEvaluation(value = (flags[key] as? Int) ?: defaultValue)
+    override fun getDoubleEvaluation(key: String, defaultValue: Double, context: EvaluationContext?) =
+        ProviderEvaluation(value = (flags[key] as? Double) ?: defaultValue)
+    override fun getObjectEvaluation(key: String, defaultValue: Value, context: EvaluationContext?) =
+        ProviderEvaluation(value = (flags[key] as? Value) ?: defaultValue)
+
+    override fun observe(): Flow<OpenFeatureProviderEvents> = events
+}
+
+class CheckoutFlagsTest {
+    private lateinit var client: Client
+
+    @Before
+    fun setUp() = runTest {
+        OpenFeatureAPI.setProviderAndWait(
+            FakeProvider(mapOf("new-checkout-flow" to true))
+        )
+        client = OpenFeatureAPI.getClient()
+    }
+
+    @Test
+    fun newCheckoutEnabled() {
+        assertTrue(client.getBooleanValue("new-checkout-flow", false))
+    }
+}
+{{< /code-block >}}
+
+`OpenFeatureAPI` is a process-wide singleton, so reset it between test classes if tests share a JVM. Wrap `setProviderAndWait` in `runTest { ... }` — it cannot be called from a plain `@Before` method because it is `suspend`.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
 [1]: https://openfeature.dev/
 [2]: /account_management/api-app-keys/#client-tokens
+[3]: https://github.com/open-feature/kotlin-sdk/pull/226
@@ -253,6 +253,108 @@ print(details.error)    // The error that occurred during evaluation, if any
 
 Flag details may help you debug evaluation behavior and understand why a user received a given value.
 
+## Use with OpenFeature
+
+The examples above use Datadog's `FlagsClient` API directly. If you prefer the [OpenFeature](https://openfeature.dev/) standard API, Datadog ships an OpenFeature provider for iOS that wraps `FlagsClient` and exposes it through `OpenFeatureAPI.shared`. The same flag data is served through either surface; pick whichever API fits your app.
+
+<div class="alert alert-warning">The iOS OpenFeature bridge (<a href="https://github.com/DataDog/dd-openfeature-provider-swift"><code>dd-openfeature-provider-swift</code></a>) is in development and not recommended for production use. Use the <code>FlagsClient</code> API shown above for production workloads; use this section to prototype OpenFeature integrations or to structure tests around the OpenFeature API.</div>
+
+### Install the OpenFeature provider
+
+Add `dd-openfeature-provider-swift` to your `Package.swift`:
+
+{{< code-block lang="swift" filename="Package.swift" >}}
+.package(url: "https://github.com/DataDog/dd-openfeature-provider-swift.git", .upToNextMajor(from: "0.1.0"))
+{{< /code-block >}}
+
+Link the `DatadogOpenFeatureProvider` product to your app target. The bridge depends on OpenFeature Swift SDK 0.3.0.
+
+### Initialize OpenFeature
+
+Initialize Datadog and enable Flags as shown in [Initialize the SDK](#initialize-the-sdk). Then create a `DatadogProvider` and register it with `OpenFeatureAPI.shared`:
+
+{{< code-block lang="swift" >}}
+import DatadogCore
+import DatadogFlags
+import DatadogOpenFeatureProvider
+import OpenFeature
+
+Datadog.initialize(
+    with: Datadog.Configuration(
+        clientToken: "<client token>",
+        env: "<environment>",
+        site: .{{< region-param key="dd_datacenter_lowercase" code="true" >}},
+        service: "<service name>"
+    ),
+    trackingConsent: .granted
+)
+
+Flags.enable()
+
+let context = MutableContext(targetingKey: "user-123")
+let provider = DatadogProvider()
+await OpenFeatureAPI.shared.setProviderAndWait(provider: provider, initialContext: context)
+{{< /code-block >}}
+
+`setProviderAndWait` is `async` and does not throw. After it returns, the provider is ready and flag evaluations use cached values.
+
+### Set the evaluation context
+
+The evaluation context identifies who or what the flag evaluation applies to. Pass it at provider registration, as shown above, or update it later:
+
+{{< code-block lang="swift" >}}
+let updatedContext = MutableContext(
+    targetingKey: "user-123",
+    structure: MutableStructure(attributes: [
+        "email": Value.string("user@example.com"),
+        "tier":  Value.string("premium")
+    ])
+)
+
+await OpenFeatureAPI.shared.setEvaluationContextAndWait(evaluationContext: updatedContext)
+{{< /code-block >}}
+
+The `targetingKey` is the randomization subject for percentage rollouts — the same key always receives the same variant for a given flag.
+
+### Evaluate flags
+
+Retrieve the global OpenFeature client and call the typed getters:
+
+{{< code-block lang="swift" >}}
+let client = OpenFeatureAPI.shared.getClient()
+
+let isNewCheckoutEnabled = client.getBooleanValue(key: "checkout.new", defaultValue: false)
+
+let theme = client.getStringValue(key: "ui.theme", defaultValue: "light")
+
+let maxItems = client.getIntegerValue(key: "cart.items.max", defaultValue: 20)
+
+let priceMultiplier = client.getDoubleValue(key: "pricing.multiplier", defaultValue: 1.0)
+
+let config = client.getObjectValue(
+    key: "ui.config",
+    defaultValue: Value.structure([
+        "color": Value.string("#00A3FF"),
+        "fontSize": Value.integer(14)
+    ])
+)
+{{< /code-block >}}
+
+Evaluations are synchronous and safe to perform on the main thread — they read from the SDK's local cache and do not make network requests. Note that `getIntegerValue` returns `Int64`; cast to `Int` at the call site if needed.
+
+### Flag evaluation details
+
+Use the `get<Type>Details` methods when you need the reason, variant, or any evaluation error in addition to the value:
+
+{{< code-block lang="swift" >}}
+let details = client.getStringDetails(key: "paywall.layout", defaultValue: "control")
+
+print(details.value)    // Evaluated value
+print(details.variant)  // Variant name, if applicable
+print(details.reason)   // Reason (for example: "TARGETING_MATCH" or "DEFAULT")
+print(details.errorCode) // Error code, if evaluation failed
+{{< /code-block >}}
+
 ## Advanced configuration
 
 The `Flags.enable()` API accepts optional configuration with options listed below.
@@ -288,6 +390,77 @@ Flags.enable(with: config)
 `customFlagsHeaders`
 : Sets additional HTTP headers to attach to requests made to `customFlagsEndpoint`. It can be useful for authentication or routing when using your own flags service.
 
+## Testing
+
+The examples above use Datadog's `FlagsClient` API directly. If you prefer to drive feature flags through the [OpenFeature](https://openfeature.dev/) standard API, Datadog ships an OpenFeature bridge for iOS at [dd-openfeature-provider-swift](https://github.com/DataDog/dd-openfeature-provider-swift). Use the bridge's `DatadogProvider` in production, and for code-controlled flag values in tests, substitute an in-memory provider.
+
+You can test against a dedicated Datadog test environment with the real `DatadogProvider`, or swap it for an in-memory `FeatureProvider` to control flag values directly in test code. This section shows the in-memory approach, which keeps tests hermetic and offline. The OpenFeature Swift SDK does not ship an `InMemoryProvider`, so tests use a small custom `FeatureProvider` instead.
+
+{{< code-block lang="swift" >}}
+import Combine
+import OpenFeature
+import XCTest
+@testable import MyApp
+
+// Minimal in-memory provider for tests. Copy into your test target.
+final class InMemoryTestProvider: FeatureProvider {
+    var hooks: [any Hook] = []
+    var metadata: ProviderMetadata = Metadata(name: "in-memory-test")
+    private let subject = CurrentValueSubject<ProviderEvent?, Never>(.ready)
+    private let bools: [String: Bool]
+    private let strings: [String: String]
+
+    init(bools: [String: Bool] = [:], strings: [String: String] = [:]) {
+        self.bools = bools
+        self.strings = strings
+    }
+
+    func observe() -> AnyPublisher<ProviderEvent?, Never> { subject.eraseToAnyPublisher() }
+
+    func initialize(initialContext: EvaluationContext?) async throws {}
+
+    func onContextSet(oldContext: EvaluationContext?, newContext: EvaluationContext) async throws {}
+
+    func getBooleanEvaluation(key: String, defaultValue: Bool, context: EvaluationContext?) throws -> ProviderEvaluation<Bool> {
+        ProviderEvaluation(value: bools[key] ?? defaultValue, variant: bools[key] == nil ? "default" : "static", reason: Reason.staticReason.rawValue)
+    }
+
+    func getStringEvaluation(key: String, defaultValue: String, context: EvaluationContext?) throws -> ProviderEvaluation<String> {
+        ProviderEvaluation(value: strings[key] ?? defaultValue, variant: strings[key] == nil ? "default" : "static", reason: Reason.staticReason.rawValue)
+    }
+
+    func getIntegerEvaluation(key: String, defaultValue: Int64, context: EvaluationContext?) throws -> ProviderEvaluation<Int64> {
+        ProviderEvaluation(value: defaultValue, variant: "default", reason: Reason.staticReason.rawValue)
+    }
+
+    func getDoubleEvaluation(key: String, defaultValue: Double, context: EvaluationContext?) throws -> ProviderEvaluation<Double> {
+        ProviderEvaluation(value: defaultValue, variant: "default", reason: Reason.staticReason.rawValue)
+    }
+
+    func getObjectEvaluation(key: String, defaultValue: Value, context: EvaluationContext?) throws -> ProviderEvaluation<Value> {
+        ProviderEvaluation(value: defaultValue, variant: "default", reason: Reason.staticReason.rawValue)
+    }
+
+    private struct Metadata: ProviderMetadata { var name: String? }
+}
+
+final class CheckoutFlagTests: XCTestCase {
+    override func tearDown() {
+        OpenFeatureAPI.shared.clearProvider()
+    }
+
+    func testNewCheckoutEnabled() async throws {
+        let provider = InMemoryTestProvider(bools: ["new-checkout-flow": true])
+        await OpenFeatureAPI.shared.setProviderAndWait(provider: provider)
+
+        let client = OpenFeatureAPI.shared.getClient()
+        XCTAssertTrue(client.getBooleanValue(key: "new-checkout-flow", defaultValue: false))
+    }
+}
+{{< /code-block >}}
+
+`OpenFeatureAPI.shared` is a global singleton, so call `clearProvider()` in `tearDown` to prevent one test's flags from leaking into another. `setProviderAndWait(provider:)` is `async` and does not throw, so no `try` is required.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
@@ -199,6 +199,50 @@ await OpenFeature.setContext({
 });
 {{< /code-block >}}
 
+## Testing
+
+You can test against a dedicated Datadog test environment with the real `DatadogProvider`, or swap it for OpenFeature's `InMemoryProvider` to control flag values directly in test code. This section shows the in-memory approach, which keeps tests hermetic and offline. `InMemoryProvider` is exported directly from `@openfeature/web-sdk`, so no additional dependency is required.
+
+Unlike the server-side SDK, the Web SDK evaluates flags synchronously after initialization. Still `await` `setProviderAndWait` once in `beforeEach` to ensure the provider is ready.
+
+{{< code-block lang="javascript" >}}
+import { beforeEach, afterAll, expect, test } from 'vitest';
+import { OpenFeature, TypedInMemoryProvider } from '@openfeature/web-sdk';
+
+const flags = {
+  new_checkout_button: {
+    variants: { on: true, off: false },
+    defaultVariant: 'on',
+    disabled: false,
+  },
+  ui_theme: {
+    variants: { dark: 'dark', light: 'light' },
+    defaultVariant: 'light',
+    disabled: false,
+  },
+};
+
+beforeEach(async () => {
+  await OpenFeature.setProviderAndWait(new TypedInMemoryProvider(flags));
+});
+
+afterAll(async () => {
+  await OpenFeature.close();
+});
+
+test('new checkout button is enabled by default', () => {
+  const client = OpenFeature.getClient();
+  expect(client.getBooleanValue('new_checkout_button', false)).toBe(true);
+});
+
+test('missing flag returns default', () => {
+  const client = OpenFeature.getClient();
+  expect(client.getBooleanValue('does-not-exist', false)).toBe(false);
+});
+{{< /code-block >}}
+
+The Web SDK flag shape requires `variants`, `defaultVariant`, and `disabled`. Omitting any of these fails TypeScript compilation; at runtime, evaluating an unknown flag key returns the supplied default. Prefer `TypedInMemoryProvider` over the deprecated `InMemoryProvider` for type-checked flag configurations. The same test pattern works with Jest + jsdom; swap the `vitest` imports for `@jest/globals` and add `jest-environment-jsdom` to your project.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
@@ -293,6 +293,25 @@ await OpenFeature.setContext({
 });
 {{< /code-block >}}
 
+## Testing
+
+You can test against a dedicated Datadog test environment with the real `DatadogProvider`, or swap it for OpenFeature's `TypedInMemoryProvider` to control flag values directly in test code. This section shows the in-memory approach, which keeps tests hermetic and offline. `TypedInMemoryProvider` is exported from `@openfeature/web-sdk`; install it as a development dependency and register it before rendering components under test:
+
+{{< code-block lang="javascript" >}}
+import { OpenFeature } from '@openfeature/react-sdk';
+import { TypedInMemoryProvider } from '@openfeature/web-sdk';
+
+await OpenFeature.setProviderAndWait(new TypedInMemoryProvider({
+  new_checkout_button: {
+    variants: { on: true, off: false },
+    defaultVariant: 'on',
+    disabled: false,
+  },
+}));
+{{< /code-block >}}
+
+The Web SDK flag shape requires `variants`, `defaultVariant`, and `disabled`. Use `setProviderAndWait` (not `setProvider`) to avoid suspense races when the test renders flag-gated components immediately. For component tests that mount a React tree, `@openfeature/react-sdk` also exports an `OpenFeatureTestProvider` component that wraps children with an in-memory provider — see the [OpenFeature React SDK docs](https://openfeature.dev/docs/reference/technologies/client/web/react) for details.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
@@ -70,6 +70,24 @@ DD_METRICS_OTEL_ENABLED=true
 
 <div class="alert alert-info">Set <code>DD_METRICS_OTEL_ENABLED=true</code> to enable flag evaluation metrics. Without this, the SDK does not emit metrics for flag evaluations. When enabled, each evaluation records a <code>feature_flag.evaluations</code> counter metric tagged with the flag key, result variant, and evaluation reason.</div>
 
+## Testing with in-memory providers
+
+Datadog supports these testing approaches:
+
+- **Integration tests**: Point `DatadogProvider` at a dedicated test environment and control flag values from the Datadog UI. This exercises the real provider end-to-end, including Remote Configuration delivery.
+- **Unit tests**: Swap `DatadogProvider` for OpenFeature's standard `InMemoryProvider` (or an equivalent test stub, where no in-memory provider is available in the language) and set flag values directly in test code. This keeps tests hermetic and offline.
+
+This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.
+
+A typical test follows this pattern:
+
+1. Build a map of flag keys to variants in your test setup.
+2. Register an `InMemoryProvider` with that map through the OpenFeature API.
+3. Call the OpenFeature client in the units being tested. The `InMemoryProvider` returns the flag assignments configured at test setup.
+4. Reset the provider in test teardown to avoid cross-test state leakage.
+
+See your language's SDK page (select from the top of this page) for a concrete test example.
+
 ## Context attribute requirements
 
 <div class="alert alert-warning">