Write an integration test proving an authenticated user can call `GET /api/profile` while an anonymous request receives 401.

• Replace authentication only in the test host.
• Use an isolated fake, in-memory store, or disposable test database.
• Assert response data, not only status.
• Keep production authentication registration unchanged.

I use WebApplicationFactory because this behavior belongs at the HTTP boundary. A test scheme turns explicit headers into claims, while test services isolate external dependencies. Separate anonymous and authenticated requests prove both sides of the boundary.

[Fact]
public async Task Profile_requires_authentication_and_returns_current_user()
{
    await using var factory = new ApiTestFactory();

    var anonymous = factory.CreateClient();
    var denied = await anonymous.GetAsync("/api/profile");
    Assert.Equal(HttpStatusCode.Unauthorized, denied.StatusCode);

    var authenticated = factory.CreateClient();
    authenticated.DefaultRequestHeaders.Add("X-Test-User", "42");
    authenticated.DefaultRequestHeaders.Add("X-Test-Capabilities", "profile.read.own");

    var response = await authenticated.GetAsync("/api/profile");
    response.EnsureSuccessStatusCode();

    var profile = await response.Content.ReadFromJsonAsync<ProfileResponse>();
    Assert.Equal("42", profile!.UserId);
}

This is a focused API integration test: it validates middleware and endpoint wiring while replacing external identity and data dependencies. It should run against test-only state and leave no local or production content behind.

• Authentication succeeds but the capability is absent.
• The test header is missing or malformed.
• A production authentication handler is accidentally still active.
• Parallel tests share mutable fake state.

• Assert the anonymous challenge rather than manually omitting controller calls.
• Verify claims are derived only by the test scheme.
• Run tests in parallel to expose shared-state leakage.

• Calling the controller method directly and skipping middleware.
• Using a real login or identity provider in tests.
• Testing only the 200 path.
• Letting test authentication activate outside the test environment.