Test Your Polly Resilience Strategies Effectively with Simmy

A Polly resilience policy is only as good as the faults it has been tested against. Without a systematic way to inject failures, you are left hoping that your retry or fallback logic is correct — only finding out when a real dependency fails in production. Simmy closes that gap by letting you inject precisely the right fault, at the right injection rate, in ordinary unit and integration tests. The key insight is that an injection rate of 1.0 makes a chaos policy fully deterministic: it always fires. That predictability is what makes Simmy so useful in automated tests — you get a repeatable, reproducible failure scenario without any mocking infrastructure.

Unit Testing Pattern

In unit tests you want complete control. Set the injection rate to 1.0 so the fault fires on every execution, then wrap your resilience policy under test in a Policy.Wrap with the chaos policy innermost.

Build the chaos policy with 100 % injection rate

Always inject the fault so the test is deterministic. The Enabled() call with no argument defaults to true.

var fault = new HttpRequestException("Service unavailable");

var chaosPolicy = MonkeyPolicy.InjectException(with =>
    with.Fault(fault)
        .InjectionRate(1.0) // Always inject in unit tests
        .Enabled()
);

Wrap with the resilience policy under test

Place the chaos policy innermost so the outer resilience policy (retry, circuit breaker, fallback) reacts to the injected fault — exactly as it would react to a real dependency failure.

// myRetryPolicy = Policy.Handle<HttpRequestException>()
//                       .Retry(3);

var policyWrap = Policy.Wrap(myRetryPolicy, chaosPolicy);

Execute and assert

Run the wrapped execution and verify the resilience policy behaved as expected.

var callCount = 0;

// The retry policy should attempt the call 1 + 3 = 4 times before giving up
Assert.Throws<HttpRequestException>(() =>
    policyWrap.Execute(() =>
    {
        callCount++;
        return GetFromService(); // chaos will throw before this returns
    })
);

Assert.Equal(4, callCount); // initial attempt + 3 retries

Testing Individual Resilience Scenarios

Retry fires on injected exception
Circuit breaker opens under sustained faults
Fallback returns correct value
Injected HTTP result (503)

Verify that your retry policy retries the correct number of times when Simmy injects the exception it handles.

var retryCount = 0;

var retryPolicy = Policy
    .Handle<SocketException>()
    .Retry(3, onRetry: (_, __) => retryCount++);

var chaosPolicy = MonkeyPolicy.InjectException(with =>
    with.Fault(new SocketException(errorCode: 10013))
        .InjectionRate(1.0)
        .Enabled()
);

var policyWrap = Policy.Wrap(retryPolicy, chaosPolicy);

Assert.Throws<SocketException>(() =>
    policyWrap.Execute(() => CallExternalService())
);

Assert.Equal(3, retryCount);

Verify the circuit opens after the threshold is reached by injecting enough consecutive failures.

var circuitBreaker = Policy
    .Handle<HttpRequestException>()
    .CircuitBreaker(exceptionsAllowedBeforeBreaking: 2, durationOfBreak: TimeSpan.FromSeconds(30));

var chaosPolicy = MonkeyPolicy.InjectException(with =>
    with.Fault(new HttpRequestException("Injected failure"))
        .InjectionRate(1.0)
        .Enabled()
);

var policyWrap = Policy.Wrap(circuitBreaker, chaosPolicy);

// First two calls trip the breaker
Assert.Throws<HttpRequestException>(() => policyWrap.Execute(() => CallService()));
Assert.Throws<HttpRequestException>(() => policyWrap.Execute(() => CallService()));

// Third call should throw BrokenCircuitException — circuit is open
Assert.Throws<BrokenCircuitException>(() => policyWrap.Execute(() => CallService()));

Verify that your fallback policy returns the expected substitute value when Simmy injects a fault.

var fallback = Policy<string>
    .Handle<TimeoutException>()
    .Fallback("default-value");

var chaosPolicy = MonkeyPolicy.InjectException(with =>
    with.Fault(new TimeoutException("Injected timeout"))
        .InjectionRate(1.0)
        .Enabled()
);

var policyWrap = Policy.Wrap(fallback, chaosPolicy);

var result = policyWrap.Execute(() => GetCachedValue());

Assert.Equal("default-value", result);

Use InjectResult when you want to test how your code handles a bad HttpResponseMessage rather than an exception — for example when your retry policy is keyed on response status codes.

var retryPolicy = Policy<HttpResponseMessage>
    .HandleResult(r => (int)r.StatusCode >= 500)
    .Retry(2);

var chaosPolicy = MonkeyPolicy.InjectResult<HttpResponseMessage>(with =>
    with.Result(new HttpResponseMessage(HttpStatusCode.ServiceUnavailable))
        .InjectionRate(1.0)
        .Enabled()
);

var policyWrap = Policy.Wrap(retryPolicy, chaosPolicy);

var callCount = 0;
var response = policyWrap.Execute(() =>
{
    callCount++;
    // Chaos returns 503 before the real call is made
    return new HttpResponseMessage(HttpStatusCode.OK);
});

// Retried twice: 1 initial + 2 retries, all return 503 from chaos
Assert.Equal(3, callCount);
Assert.Equal(HttpStatusCode.ServiceUnavailable, response.StatusCode);

Async Test Pattern

For async code paths use the Async variants of all Simmy factory methods and pass a CancellationToken through.

var fault = new HttpRequestException("Async injected fault");

var chaosPolicy = MonkeyPolicy.InjectExceptionAsync(with =>
    with.Fault(fault)
        .InjectionRate(1.0)
        .Enabled()
);

var retryPolicy = Policy
    .Handle<HttpRequestException>()
    .RetryAsync(3);

var policyWrap = Policy.WrapAsync(retryPolicy, chaosPolicy);

var callCount = 0;

await Assert.ThrowsAsync<HttpRequestException>(async () =>
    await policyWrap.ExecuteAsync(async ct =>
    {
        callCount++;
        return await httpClient.GetAsync("/api/resource", ct);
    }, CancellationToken.None)
);

Assert.Equal(4, callCount); // 1 initial + 3 retries

Integration Testing with Low Injection Rates

In integration or load tests you typically want to simulate realistic conditions rather than forcing every call to fail. Use a low injection rate (0.01–0.05) and run enough iterations that you can statistically verify your system degrades gracefully.

var chaosPolicy = MonkeyPolicy.InjectLatencyAsync(with =>
    with.Latency(TimeSpan.FromSeconds(3))
        .InjectionRate(0.05) // ~5 % of calls get extra latency
        .Enabled()
);

var timeoutPolicy = Policy.TimeoutAsync<HttpResponseMessage>(TimeSpan.FromSeconds(2));

var policyWrap = Policy.WrapAsync(timeoutPolicy, chaosPolicy);

var timeouts = 0;

for (var i = 0; i < 200; i++)
{
    try
    {
        await policyWrap.ExecuteAsync(ct =>
            httpClient.GetAsync("/api/health", ct), CancellationToken.None);
    }
    catch (TimeoutRejectedException)
    {
        timeouts++;
    }
}

// With 5 % latency injection over 200 calls, expect roughly 10 timeouts
Assert.InRange(timeouts, 1, 30);

Low injection rates produce non-deterministic outcomes. Reserve them for integration or load tests where approximate ranges are acceptable assertions; use 1.0 whenever you need a hard guarantee in a unit test.

Frequently Asked Questions

Why do I need Simmy when I can just mock the dependency?

Mocking replaces the dependency entirely, so your resilience policy never executes. Simmy keeps the real execution path intact and injects the fault inside the policy boundary, which means the retry, circuit breaker, or fallback you have configured actually runs and must handle the fault. This tests the policy wiring, not just the happy-path logic.

Can I inject a fault only for a specific operation in a test?

Yes. Tag the Execute call with a Context carrying an OperationKey, then use EnabledWhen to gate the fault on that key.

var chaosPolicy = MonkeyPolicy.InjectException(with =>
    with.Fault(new TimeoutException())
        .InjectionRate(1.0)
        .EnabledWhen((ctx, ct) => ctx.OperationKey == "GetOrder")
);

var context = new Context("GetOrder");
policyWrap.Execute(ctx => GetOrder(), context);

How do I test InjectLatency without slowing down my test suite?

Use a short latency value — even TimeSpan.FromMilliseconds(100) — paired with a tight timeout policy. The goal is not to simulate the exact production latency value but to verify that your timeout policy fires when latency crosses its threshold.

var chaosPolicy = MonkeyPolicy.InjectLatencyAsync(with =>
    with.Latency(TimeSpan.FromMilliseconds(200))
        .InjectionRate(1.0)
        .Enabled()
);

// Timeout threshold is 100 ms — the 200 ms latency will always trip it
var timeoutPolicy = Policy.TimeoutAsync(TimeSpan.FromMilliseconds(100));
var policyWrap = Policy.WrapAsync(timeoutPolicy, chaosPolicy);

await Assert.ThrowsAsync<TimeoutRejectedException>(async () =>
    await policyWrap.ExecuteAsync(ct => Task.Delay(0, ct), CancellationToken.None)
);

Do I need a separate chaos policy per fault type?

Yes — each MonkeyPolicy injects one category of fault (exception, result, latency, or behaviour). If you want to test the interaction of multiple fault types in the same scenario, build separate policies and add them both to your PolicyWrap. Order them innermost-first so each outer resilience policy sees the combined effects.

Can I use InjectBehaviour to simulate a partial outage?

Yes. InjectBehaviour lets you run any arbitrary Action before the real call is placed. You can use it to corrupt shared state, write a poison entry to a cache, or close a connection — anything that would degrade the call in a realistic way.

var chaosPolicy = MonkeyPolicy.InjectBehaviour(with =>
    with.Behaviour(() => cache.Invalidate("orders"))
        .InjectionRate(0.10)
        .EnabledWhen((ctx, ct) => isEnabled(ctx, ct))
);

Get Started

Chaos Policies

Configuration

Guides

Test Your Polly Resilience Strategies Effectively with Simmy

Unit Testing Pattern

Testing Individual Resilience Scenarios

Async Test Pattern

Integration Testing with Low Injection Rates

Frequently Asked Questions

Build docs developers (and LLMs) love

Get Started

Chaos Policies

Configuration

Guides

Documentation Index

​Unit Testing Pattern

​Testing Individual Resilience Scenarios

​Async Test Pattern

​Integration Testing with Low Injection Rates

​Frequently Asked Questions

Build docs developers (and LLMs) love

Unit Testing Pattern

Testing Individual Resilience Scenarios

Async Test Pattern

Integration Testing with Low Injection Rates

Frequently Asked Questions