Choosing Your Approach

There are three ways to integrate CosmosDB.InMemoryEmulator into your tests. All three use FakeCosmosHandler under the hood — a real CosmosClient with an intercepted HTTP layer that provides full SDK fidelity, zero production code changes, and features like fault injection and query logging. See How It Works for a detailed comparison with other in-memory implementations.

Decision Flowchart

1. How do you wire it up?
   ├── System uses Dependency Injection?
   │   ├── Code depends on CosmosClient? → UseInMemoryCosmosDB()
   │   │   ├── Single CosmosClient? → Pattern 1 or 3
   │   │   ├── Typed CosmosClient subclasses? → Pattern 2
   │   │   └── Custom factory interface? → Pattern 5
   │   └── Code depends on Container only? → UseInMemoryCosmosContainers() (Pattern 4)
   └── No Dependency Injection / unit test? → InMemoryCosmos.Create() or InMemoryCosmos.Builder()

See the Setup Guide for detailed setup instructions for every pattern.

---

At a Glance

	Dependency Injection Extensions — Full	Dependency Injection Extensions — Container Only	Direct Instantiation
One-liner	services.UseInMemoryCosmosDB()	services.UseInMemoryCosmosContainers()	InMemoryCosmos.Create(...)
Requires Dependency Injection	Yes	Yes	No
Replaces	CosmosClient + Container	Container only	N/A — creates its own client
Auto-detects registrations	Yes	Yes	N/A
Test setup & fault injection	Dependency Injection callbacks	Dependency Injection callbacks	cosmos.SetupContainer() / cosmos.Handler
Best for	Integration tests with WebApplicationFactory	Repos that depend on Container directly	Unit/component tests without Dependency Injection

---

Dependency Injection Extensions — Full (UseInMemoryCosmosDB)

Default choice for most projects. Replaces both CosmosClient and Container registrations with in-memory equivalents backed by FakeCosmosHandler. One line of setup in ConfigureTestServices().

Supports five Dependency Injection patterns: singleton client, typed CosmosClient subclasses, GetContainer() repos, container-only, and custom factory interfaces.

Full setup guide with all patterns and code →

---

Dependency Injection Extensions — Container Only (UseInMemoryCosmosContainers)

Replaces only Container registrations, leaving the production CosmosClient untouched. Uses FakeCosmosHandler internally (new in 4.0) — same full SDK fidelity.

Use this when repositories depend on Container directly (injected via Dependency Injection) and you want to keep the production CosmosClient for other purposes.

⚠️ Only replaces Container instances resolved directly from Dependency Injection. If production code calls CosmosClient.GetContainer(), those containers bypass the in-memory handler. Use UseInMemoryCosmosDB() instead for that scenario.

Full setup guide →

---

Direct Instantiation (InMemoryCosmos)

No Dependency Injection required. The simplest way to get full SDK fidelity in unit/component tests. Handles all FakeCosmosHandler wiring internally. Use InMemoryCosmos.Create() for a single container, or InMemoryCosmos.Builder() for multi-container setups.

Full setup guide →

---

See Also

• Setup Guide — step-by-step setup with code examples for every pattern
• Getting Started — installation and quick start
• How It Works — architecture and comparison with other implementations
• How Does ToFeedIterator() Work? — LINQ .ToFeedIterator() support across approaches
• Unit Testing — simpler unit tests without Dependency Injection
• API Reference — full API documentation