How does Microsoft.AspNetCore.Mvc.Testing CreateClient work? (Testing the TestServer via UI playwright tests)

[thomhurst]

When we're using an in-memory TestServer, how does the HttpClient returned from CreateClient or CreateDefaultClient work?

When doing UI testing via Playwright, we can't just navigate to localhost, because it's not actually running a server AFAIK and the only way to talk to it is through that HttpClient?

The workarounds online are instead not using the test server, and actually running Kestrel locally, which kinda defeats the purpose I feel?

I raised a feature request to allow us to resolve requests in Playwright via a custom HttpClient, but I don't know if that'll happen: microsoft/playwright-dotnet#3089

It'd be nice to run through UI tests via a browser, while still using the TestServer and not having to spin up a real server.

[martincostello]

TestServer is entirely in memory, so it's not listening on any port an external process like a browser can access.

You can build on top of WebApplicationFactory to use a real server while still be able to do things like override services and config from test code.

There's an example of how you can do that in this sample repo of mine: https://github.com/martincostello/dotnet-minimal-api-integration-testing

[thomhurst]

Yeah that's what we're doing at the moment, but I assume booting up new servers as opposed to in-memory ones is causing some performance hits when running test suites, as they usually incur a start up cost?

I tried fulfilling routes through the HttpClient, which does work, apart from redirects annoyingly. And since our app uses redirects around things like auth flows, we're unable to use the in-memory server.

[martincostello]

For redirects the approach I've used is to reconfigure the OAuthOptions to redirect back to the app itself which then just bounces again the sign-in endpoint with the relevant state retained.

There is a small hit from starting up the full server, but if you re-use the fixture for all tests then the cost is negligible overall.

I think if you want real browser UI tests then that's the reality as the browser's going to always be an external process and need a URL to connect with. Otherwise you'd need to do things like BUnit does and manually parse the HTML to assert things, but you'll be packing the ability like click buttons and interact with it like a real user would.