mocking-microcks-dotnet

Default .NET adapter: mocks a downstream dependency from its OpenAPI/examples contract via a MicrocksContainerEnsemble, and wires the SUT’s client at the mock endpoint.

When to use

When mocking-strategy-roster resolved (microcks, .NET)
Setting up a MicrocksContainerEnsemble seeded from the downstream dependency’s contract
Pointing the SUT’s HttpClient at the Microcks mock endpoint via UseSetting

Entry contract

Strategy resolved as microcks, stack as .NET by mocking-strategy-roster
Downstream dependency’s OpenAPI / examples contract artifact path
SUT configuration key for the downstream base URL (for UseSetting)

Exit contract

{Sut}WebApplicationFactory<TProgram> with MicrocksContainerEnsemble + WithMainArtifacts(...) + GetRestMockEndpoint(name, version) → UseSetting
Structured result block: strategy, stack, files[], testCommand

Invariants

Mock the downstream dependency, not the SUT — the container stands in for what the SUT calls
GetRestMockEndpoint(name, version) — note: + encodes a space in the service name (e.g. "API+Pastries")
VerifyAsync / GetServiceInvocationsCountAsync — consumer-side only: assert the mock was called; NOT provider contract conformance
NuGet: Microcks.Testcontainers + Testcontainers (do not reference unrelated TestContainers packages)
Test command via resolving-stack-commands — never hardcode dotnet test

Why this shape

A Microcks container replays the downstream’s published contract examples as a live mock, ensuring the SUT’s client serialization and routing match what the contract specifies — without coupling to a real live service.

« Consumer-driven contracts let the consumer specify what it needs from a provider. » — Newman, S., Building Microservices, 2nd ed., 2021.

Allowed customisation

Microcks image version in MicrocksContainerEnsemble constructor (L1)
Additional artifacts loaded via WithMainArtifacts(...) for multi-downstream scenarios (L2)