Add simulated network failures ThrowsException/TimesOut

[dennisdoomen]

Closes #116

Stacking

This is the top of a 3-PR stack and targets dennisdoomen/response-latency-after:

• Stacks on Add simulated response latency .After(TimeSpan) #134 (issue Add simulated response latency (.After(TimeSpan)) for timeout/cancellation/resilience testing #117 — response latency / After())
• Which stacks on Add async responder overloads and CancellationToken flow #132 (issue Add async responder overloads and flow CancellationToken into responders #120 — async responder pipeline / CancellationToken threading)

It builds on the async responder path (TrackRequestAsync, CancellationToken flowing from SendAsync → HandleRequest → RequestMock) introduced in those PRs and does not re-implement them.

Summary

Adds first-class support for simulating network-level failures so tests can exercise retry, circuit-breaker and error-handling code.

Previously the pipeline swallowed every responder exception and turned it into a 500 response, so there was no way to simulate a thrown transport error. This change introduces a dedicated simulated-failure responder that the async pipeline propagates to the HttpClient caller instead of catching:

• A new internal SimulatedFailureResponder type represents an intentionally simulated failure.
• RequestMock.TrackRequestAsync records the request (incrementing the invocation count and adding it to any request collection) and returns the captured request carrying the exception, rather than throwing inline. This guarantees the failed call is recorded in HttpMock.Requests (as expected/handled) before the exception reaches the caller.
• HttpMock.HandleRequest rethrows the captured exception via ExceptionDispatchInfo after recording it.
• The existing try/catch that converts responder exceptions into a 500 is carefully scoped so genuine bugs in user RespondsWith responders keep the current 500 behavior, while intentionally-simulated failures propagate.
• Once() / Times(n) and After() continue to apply to simulated failures.

New public API

RequestMockResponseBuilder ThrowsException(Exception exception);
RequestMockResponseBuilder ThrowsException<TException>() where TException : Exception, new();
RequestMockResponseBuilder TimesOut(); // throws TaskCanceledException, mimicking an HttpClient timeout

Plus CapturedRequest.SimulatedFailure (Exception?) so a captured entry can be inspected to tell a simulated throw apart from an unexpected 500.

Usage:

mock.ForGet().WithPath("/flaky").ThrowsException<HttpRequestException>();
mock.ForGet().WithPath("/slow").TimesOut();

This is additive and backward-compatible. The API verification baselines (net8.0, net472) were regenerated via AcceptApiChanges.ps1.

Tests

New WhenSimulatingNetworkFailures spec class (xUnit + FluentAssertions, AAA) covering:

• HttpRequestException surfaces to the HttpClient caller (generic and specific-instance overloads)
• TimesOut() throws TaskCanceledException
• the failed call is captured in HttpMock.Requests and in a CollectingRequestsIn collection
• Once() / Times(n) still apply
• a genuinely buggy responder still results in a 500
• null exception is rejected

All 108 specs pass on both net8.0 and net472; Release build (warnings-as-errors, all analyzers) is clean.

Follow-up

Issue #116 also describes a companion CapturedRequestAssertions.BeASimulatedFailure() assertion in the separate dennisdoomen/fluentassertions.mockly repo (v7/v8 via Shared/). That is not part of this repo/workspace and needs its own PR; the new public CapturedRequest.SimulatedFailure property is exposed here so that assertion can be built on top of it.

[github-actions]

Test Results

  3 files  ± 0    3 suites  ±0   20s ⏱️ +12s
212 tests + 9  212 ✅ + 9  0 💤 ±0  0 ❌ ±0 
421 runs  +18  421 ✅ +18  0 💤 ±0  0 ❌ ±0 

Results for commit fb6e07a. ± Comparison against base commit 5c41aba.

♻️ This comment has been updated with latest results.

[coveralls]

Coverage Report for CI Build 31386873526

Coverage increased (+0.4%) to 85.461%

Details

• Coverage increased (+0.4%) from the base build.
• Patch coverage: 50 of 50 lines across 5 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	1573
Covered Lines:	1413
Line Coverage:	89.83%
Relevant Branches:	511
Covered Branches:	368
Branch Coverage:	72.02%
Branches in Coverage %:	Yes
Coverage Strength:	337.93 hits per line

---

💛 - Coveralls