An integration test exercises multiple application components together. In ASP.NET Core, it can send a request through a middleware pipeline and check the response, rather than calling one component in isolation. This helps catch problems that a unit test may miss, such as a missing dependency-injection registration or behavior that depends on routing. section 36.3 section 36.3.3 section 36.5
Choose the smallest test host that exercises the interaction you care about:
- Use TestServer from Microsoft.AspNetCore.TestHost for a focused test of a component such as custom middleware. Configure a small web host and middleware pipeline, obtain its HttpClient, send an in-memory request, and inspect the response. No separate application or network port is needed. section 36.3.1 section 36.5
- Use WebApplicationFactory<Program> from Microsoft.AspNetCore.Mvc.Testing for a broader test of the real application. An xUnit test class can receive the factory through IClassFixture, create an HttpClient, send a request, and assert on its response. The in-memory application uses its usual configuration, services, and middleware pipeline. section 36.5
Checking an endpoint
Suppose a currency endpoint should return a converted value. A test can request /api/currency through a WebApplicationFactory client, require a successful status code, read the response body, and compare it with the expected value. Unlike a direct controller method call, the request runs in the application’s ASP.NET Core context. section 36.3.4 section 36.2
Keep external dependencies under control. A factory starts the application much as it runs locally, so its tests may use local connection strings, secrets, databases, or third-party services. Use WithWebHostBuilder() and ConfigureTestServices() to replace a dependency for one test—for example, swap an API-backed converter for a predictable stub. If many tests need the same replacement, put it in a custom WebApplicationFactory and reserve per-test overrides for exceptions. section 36.3.3 section 36.3.4 section 36.5
Listing 36.11 Using a custom WebApplicationFactory in an integration test
public class IntegrationTests: #1 IClassFixture<CustomWebApplicationFactory> #1 { private readonly CustomWebApplicationFactory _fixture; #2 public IntegrationTests(CustomWebApplicationFactory fixture) #2 { _fixture = fixture; } [Fact] public async Task ConvertReturnsExpectedValue() { HttpClient client = _fixture.CreateClient(); #3 var response = await client.GetAsync("/api/currency"); response.EnsureSuccessStatusCode(); var content = await response.Content.ReadAsStringAsync(); Assert.Equal("3", content); #4 } } #1 Implements the IClassFixture interface for the custom factory #2 Injects an instance of the factory in the constructor #3 The client already contains the test service configuration. #4 The result confirms that the test service was used.
The test uses a custom factory as an xUnit fixture, sends an in-memory HTTP request, and checks the response body. section 36.3.4
Integration tests complement rather than replace unit tests. Unit tests are usually quicker and suit many valid, edge-case, and invalid inputs. Integration tests need more setup, run more slowly, and may depend on infrastructure; a smaller set can check that the tested pieces work together. section 36.3
