Web app not reachable externally(via browser/postman/curl,etc) rather than test code itself during test

[bveeni]

Before you file a bug...
I have a simple app with integration test with xunit.
Here is a sample code.

public class ChromeIntegrationTest : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly WebApplicationFactory<Program> _factory;

    public ChromeIntegrationTest(WebApplicationFactory<Program> factory)
    {
        _factory = new WebApplicationFactory<Program>();
    }

    [Fact]
    public async Task EmployeeData()
    {
        var client = _factory.CreateClient();
        var result = await client.GetAsync("/Home/GetAll");

        var responseString = await result.Content.ReadAsStringAsync();

        Assert.True(result.StatusCode == System.Net.HttpStatusCode.OK);
    }
}

When running integration test, I am able to access api(Home/GetAll) and get result as required within test code. However, during process of running test, if I try to access same api externally i.e, using curl, postman, browser etc. the api is not accessible, saying failed to connect. I was wondering if a site is reachable within test code, then why I am unable to access it via browser or any other external tool.
I would like to know if api spin up in tests are restricted to being accessible to only test http client.
If there is some other configuration, that are needed to setup, then please feel free to guide me through.
Any example of integration test using xunit, whose site is up in browser as well while running test would be highly appreciated.

Thank you

[bradwilson]

The test server which ASP.NET Core uses during integration testing runs in memory, not on TCP, so the server is not reachable externally (only via the client provided by the web app factory).

[bradwilson]

If you're curious how it works:

A fundamental interface for the HTTP pipeline in .NET is HttpMessageHandler from System.Net.Http. You send it an HttpRequestMessage and you get back an HttpResponseMessage. You can pass an HttpMessageHandler to the HttpClient constructor and it will use that whenever anybody makes a request to the client. The default constructor (no parameter) uses an implementation of HttpMessageHandler which sends your requests out via the network.

When integration testing, the ASP.NET Core team has opted instead to direct hook the server up to HttpClient and skip the network entirely. They did this for (at least) two reasons: (a) the network just adds complexity and time cost that's unnecessary, and (b) having your server listen on a port consumes ports, and depending on the cleanup process, you could easily consume all the available ports on a system.

So this is why you can't hit your test server with a browser/curl/etc., because the test server doesn't put itself on the network at all.