Build out infrastructure to share behavior tests between RDF and RDG

[captainsafia]

RDF (Request Delegate Factory) and RDG (Request Delegate Generator) have different logic for producing RequestDelegates from user handlers. However, the testing infrastructure for both approaches provides infrastructure for taking a RequestDelegate and HttpContext as input and asserting on the responses emitted. This infrastructure can be shared between the two projects so that we can construct a test library where RequestDelegates can be produced with different strategies (runtime or compile-time generation) but be run through the same tests to validate their behavior.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

I had a small epiphany and realized that this might be a lot easier to do with our overload resolution-based approach in the RequestDelegateGenertor.

At the moment, if the RequestDelegateGenerator cannot emit code for particular scenario, it will fallback to the runtime-based strategy since the strongly-typed MapAction isn't emitted. We actually already have infrastructure in our RequestDelegateGeneratorTestBase that checks to see if compile-time or runtime code generation ran based on the existence of a source key.

aspnetcore/src/Http/Http.Extensions/test/RequestDelegateGenerator/RequestDelegateGeneratorTestBase.cs

Lines 132 to 144 in 1a54913

	foreach (var endpoint in endpoints)
	{
	var sourceKeyMetadata = endpoint.Metadata.FirstOrDefault(metadata => metadata.GetType() == sourceKeyType);
	if (expectSourceKey)
	{
	Assert.NotNull(sourceKeyMetadata);
	}
	else
	{
	Assert.Null(sourceKeyMetadata);
	}
	}

We can configure the RequestDelegateGeneratorTestBase to have two modes: (a) one where the generator runs as part of the compilation step and (b) one where the generator is disabled in the compilation. In the (b) scenario, the RequestDelegate will be produced by the runtime implementation but the same assertions can still be run.

A rough layout of the test infrastructure would look like this:

public interface IRequestDelegateTestFixture
{
  public GeneratorDriver Driver { get; set; ]
}

public class GeneratorEnabledTestFixture : IDisposable, IRequestDelegateTestFixture
{
  public GeneratorDriver Driver { get; set; }
  public GeneratorEnabledTestFixture()
  {
     // Set GeneratorDriver to instance with RDG configured 
  }
}

public class FactoryEnabledTestFixture : IDisposable, IRequestDelegateTestFixture
{
  public GeneratorDriver Driver { get; set; }
  public GeneratorEnabledTestFixture()
  {
     // Set GeneratorDriver to instance *without* RDG configured so we fallback to runtime compilation
  }
}

public abstract class RouteHandlerTests
{
    protected readonly IRequestDelegateTestFixture Fixture;

    protected RouteHandlerTests(IRequestDelegateTestFixture fixture)
    {
       Fixture = fixture;
    }

    [Fact]
    public void MapAction_NoParam_StringReturn()
    {
        var source = "...";
        var (result, compilation) = Fixture.Generator.RunAsync(source);

         var endpoint = GetEndpointFromCompilation(compilation);
         var httpContext = CreateHttpContext();
         await endpoint.RequestDelegate(httpContext);

         VerifyResponseBody(httpContext, "Hello world!");
    }
}

public class RDGTests : RouteHandlerTests, IClassFixture<GeneratorEnabledTestFixture>
{
    public RDGTests(GeneratorEnabledTestFixture fixture)
       : base(fixture)
    {
    }
}

public class RDFTests : RouteHandlerTests, IClassFixture<FactoryEnabledTestFixture>
{
    public RDFTests(FactoryEnabledTestFixture fixture)
       : base(fixture)
    {
    }
}

Then we'd have to do the heavy-lifting to merge the test cases into the abstract base class (or the child classes if it makes sense to have them there).

cc: @JamesNK @halter73 @mitchdenny

[mitchdenny]

I think that this is a reasonable approach. What this does is allow us to define a test case once and execute it in each environment. What this doesn't necessarily allow us to do is directly reuse our existing test cases that are more unit-level focused against RDF - but I don't think that there was going to be a solution for that anyway.

Perhaps we should put this in now for the new RDG tests we are writing to see if there are inconsistencies we pick up with the limited test coverage we already have set up?

[JamesNK]

Low-level tests of expression trees will remain unique. Just like there are probably low-level tests for the generator, and its output.

Any test that registers a minimal API lambda and then tests running it with an HttpContext can be shared. They're kind of like in-memory functional tests. Part of this issue will be going through the existing RDF tests and moving+updating them to be sharable.

@captainsafia Injecting a fixture would be a good way to do it. I was thinking of something simpler, like a protected abstract method on the base class, but a fixture makes it easier to reuse this pattern on multiple test files.

[captainsafia]

@captainsafia Injecting a fixture would be a good way to do it. I was thinking of something simpler, like a protected abstract method on the base class, but a fixture makes it easier to reuse this pattern on multiple test files.

Yep, at the moment, we use what would be the GeneratorEnabledTestFixture in two test files. Also, being more prudent about splitting up tests into multiple files will help us avoid having a giant file with all the tests that is difficult to navigate, as we have in the RDF tests now.

What this doesn't necessarily allow us to do is directly reuse our existing test cases that are more unit-level focused against RDF - but I don't think that there was going to be a solution for that anyway.

Yep, as @JamesNK mentioned, there's also a class of tests currently in RequestDelegateFactoryTests that cannot be moved at all. We'll have to do the manual work of filtering out what these tests are and moving the others.