integration-testing-dotnet

Integration Testing for .NET

Overview

Unit tests verify logic in isolation. Integration tests verify that the pieces actually work together — that your HTTP endpoints return what the OpenAPI contract says, that your EF Core queries produce the right SQL against a real database, that your Blazor page renders what the user actually sees, that your Avalonia window wires bindings correctly. Integration tests catch the bugs that pass every unit test and fail every user interaction.

This skill covers the four integration boundaries that matter most in .NET:

1. HTTP API → Microsoft.AspNetCore.Mvc.Testing + WebApplicationFactory<TEntryPoint>
2. Database → Testcontainers.PostgreSql / Testcontainers.MsSql / Testcontainers.Redis (real providers in Docker)
3. Browser → Microsoft.Playwright (for Blazor, Razor Pages, ASP.NET Core MVC views)
4. Desktop UI → Avalonia.Headless.XUnit for Avalonia windows and view-model ↔ view bindings

When to Use

• Building or modifying anything that crosses an HTTP, database, or UI boundary
• Debugging bugs that unit tests don't catch (serialization, middleware ordering, DI lifetimes, query translation, binding failures)
• Verifying that a fix actually works against a realistic stack
• Testing that your DbContext migrations produce the expected schema
• Exercising end-to-end user flows as part of a release candidate

When NOT to use: pure domain logic (unit tests are cheaper and faster); configuration-only changes; static content changes.