Introduce Polly.Testing package

[martintmk]

Details on the issue fix or feature implementation

Contributes to #1367

With this relatively small package the consumer of Polly can assert the composition of resilience strategies with ease:

// arrange
var strategy = new ResilienceStrategyBuilder<string>()
    .AddFallback(new()
    {
        FallbackAction = _ => Outcome.FromResultAsTask("dummy"),
    })
    .AddRetry(new())
    .AddAdvancedCircuitBreaker(new())
    .AddTimeout(TimeSpan.FromSeconds(1))
    .AddHedging(new())
    .AddConcurrencyLimiter(10)
    .AddStrategy(new CustomStrategy())
    .ConfigureTelemetry(NullLoggerFactory.Instance)
    .Build();

// act
var descriptor = strategy.GetInnerStrategies();

// assert
descriptor.HasTelemetry.Should().BeTrue();
descriptor.Strategies.Should().HaveCount(7);
descriptor.Strategies[0].Options.Should().BeOfType<FallbackStrategyOptions<string>>();
descriptor.Strategies[1].Options.Should().BeOfType<RetryStrategyOptions<string>>();
descriptor.Strategies[2].Options.Should().BeOfType<AdvancedCircuitBreakerStrategyOptions<string>>();
descriptor.Strategies[3].Options.Should().BeOfType<TimeoutStrategyOptions>();
descriptor.Strategies[3].Options
    .Should()
    .BeOfType<TimeoutStrategyOptions>().Subject.Timeout
    .Should().Be(TimeSpan.FromSeconds(1));

descriptor.Strategies[4].Options.Should().BeOfType<HedgingStrategyOptions<string>>();
descriptor.Strategies[5].Options.Should().BeOfType<RateLimiterStrategyOptions>();
descriptor.Strategies[6].StrategyType.Should().Be(typeof(CustomStrategy));

cc @PeterCsalaHbo

Confirm the following

• I started this PR by branching from the head of the default branch
• I have targeted the PR to merge into the default branch
• I have included unit tests for the issue/feature
• I have successfully run a local build

[martincostello]

Suggested change

	/// This class provides additional information about <see cref="ResilienceStrategy"/>.
	/// This class provides additional information about a <see cref="ResilienceStrategy"/>.

[PeterCsalaHbo]

@martintmk Could you please modify your assertions to include a sample how to check for the AddConcurrencyLimiter's parameter as well?

[codecov]

Codecov Report

Merging #1394 (5b8fa65) into main (472e961) will increase coverage by 0.06%.
The diff coverage is 100.00%.

❗ Current head 5b8fa65 differs from pull request most recent head adb42c2. Consider uploading reports for the commit adb42c2 to get more accurate results

@@            Coverage Diff             @@
##             main    #1394      +/-   ##
==========================================
+ Coverage   83.73%   83.79%   +0.06%     
==========================================
  Files         270      273       +3     
  Lines        6449     6475      +26     
  Branches     1006     1010       +4     
==========================================
+ Hits         5400     5426      +26     
  Misses        840      840              
  Partials      209      209              

Flag	Coverage Δ
linux	?
macos	83.79% <100.00%> (+0.06%)	⬆️
windows	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/Polly.Core/ResilienceStrategy.cs	100.00% <100.00%> (ø)
src/Polly.Core/ResilienceStrategyBuilderBase.cs	100.00% <100.00%> (ø)
src/Polly.Testing/InnerStrategiesDescriptor.cs	100.00% <100.00%> (ø)
src/Polly.Testing/ResilienceStrategyDescriptor.cs	100.00% <100.00%> (ø)
src/Polly.Testing/ResilienceStrategyExtensions.cs	100.00% <100.00%> (ø)

[martincostello]

I think this is lightweight enough to be useful to people - I don't think I'd use it myself personally, but this doesn't look like it would add much maintenance burden.

One thought that occurs to me: should be call this Testing or maybe it's more like Diagnostics or Introspection? Was just thinking to myself that someone could possible have a diagnostics endpoint in their application where they might want to check the configured pipeline at runtime - in that case having to have a dependency on a package called .Testing would look a bit suspect.

[martintmk]

I think this is lightweight enough to be useful to people - I don't think I'd use it myself personally, but this doesn't look like it would add much maintenance burden.

One thought that occurs to me: should be call this Testing or maybe it's more like Diagnostics or Introspection? Was just thinking to myself that someone could possible have a diagnostics endpoint in their application where they might want to check the configured pipeline at runtime - in that case having to have a dependency on a package called .Testing would look a bit suspect.

It also shows people that we care about the testing and have native support for it.

One thought that occurs to me: should be call this Testing or maybe it's more like Diagnostics or Introspection?

I am just following the other naming convention such as Microsoft.AspNetCore.Mvc.Testing or Microsoft.Extensions.TimeProvider.Testing. It's not really something we should encourage people to use at runtime.

Was just thinking to myself that someone could possible have a diagnostics endpoint in their application where they might want to check the configured pipeline at runtime - in that case having to have a dependency on a package called .Testing would look a bit suspect.

If there is use-case for this in the future we can emit built-in telemetry without exposing any new API.

[martintmk]

@martintmk Could you please modify your assertions to include a sample how to check for the AddConcurrencyLimiter's parameter as well?

Unfortunate thing is that RateLimiting is external API and we do not have it under our control. Assertion such as that is not possible without reflection.

[martintmk]

I'll use this package to simplify tests such as these:

https://github.com/dotnet/extensions/blob/142fe1886a94e3f251e149f58e5e918161dcd7a5/test/Libraries/Microsoft.Extensions.Http.Resilience.Tests/Hedging/StandardHedgingTests.cs#L166