[Feature]: Use Custom HttpClient to resolve requests

[thomhurst]

🚀 Feature Request

I'm trying to test a .NET Web App using the Microsoft.AspNetCore.Mvc.Testing package, which allows you to run a TestServer and run everything in memory.

I actually thought this would've been a really common scenario, and Playwright being built by Microsoft, would have first class support for this scenario, but it doesn't seem the case.

There's hacky workarounds online of overriding the test server configuration, and building two(?) servers, and enabling kestrel, etc, and you're basically running a fully fledged server at that point instead of a simple in memory one.

The problem is:

The test server is only contactable via the HttpClient that it passes to you, so you must use this to interact with your app. So if in Playwright I go to the same URL, it will just give me an error page because it can't contact the requested resource, and that's because it's using its own mechanisms to fire network requests.

I've semi got things working using RouteAsync and requests through my custom client instead, and then trying to fulfil the responses, but it gets complicated/messy once you have any redirect logic in your app. And if those redirects go to external URLs (think authentication providers), and then back to your app, you have to figure out whether you can fulfil a 302 (because can Playwright contact the Location header you give it, or does that as well need to go through your custom client?), or whether you just have to do a 200 fulfil with the final response, but then the browser is unaware of redirects happening and your URL doesn't change, so it's not 100% emulating what your app would actually be doing. This can mess with things like CORS etc. if I'm not mistaken? As well as hindering tests .WaitForUrl logic.

A way that feels simple (from the user's perspective anyway, might be a lot of work your side) would be to be able to pass your own HttpClient when a new Context is created, through the BrowserNewContextOptions object. It should be nullable, and if not set, everything would behave as-is.

However, if set, then requests should be resolved via that.

Example

    public override BrowserNewContextOptions ContextOptions()
    {
        return new BrowserNewContextOptions
        {
            HttpClient = WebApplicationFactory.CreateDefaultClient()
        };
    }

Then this would successfully route through to my in-memory server, and I wouldn't have to do any custom RouteAsync logic:

await _page.GotoAsync("https://localhost");

Motivation

As mentioned, it would allow flexible and first-class support for testing in-memory applications, which I'm surprised isn't the case already as it's part of the Microsoft ecosystem.

[mxschmitt]

When intercepting network requests you can use your custom http client as you already do. We don't plan on providing custom http client interfaces in order to replace 'APIRequestContext' or 'Route.FetchAsync'. We expect redirects to be handled on the client itself. Do you mind on elaborating on what doesn't work? Ideally a small self-contained reproducible.

[thomhurst]

Here's a minimal solution reproducing problems: https://github.com/thomhurst/PlaywrightDotnet3089Repro/blob/main/ReproApp/PlaywrightTests/Tests.cs

I'm praying this doesn't just get closed with a WontFix, because this seems like something you'd want to support given the Microsoft Mvc Test package and Playwright could work together perfectly if this was supported?