Testing ASP.NET Core applications

Practical approaches to testing ASP.NET Core applications at different boundaries, from individual handlers to fully hosted applications with authentication, databases, and gRPC.

Testing an ASP.NET Core application is rarely about choosing between a “unit test” and an “integration test” in the abstract. The more useful question is how much of the application needs to be present to exercise the behavior that matters.

Sometimes the right test targets a handler directly, with only its immediate dependencies in scope. In other cases, the behavior depends on routing, authentication, dependency injection, serialization, middleware, or persistence. At that point, bringing more of the ASP.NET Core application into the test can give you much stronger confidence than testing the individual pieces in isolation.

The articles below explore that boundary from different angles: hosting the ASP.NET Core application in-process with WebApplicationFactory, testing gRPC services, exercising endpoints backed by a real database, handling authentication with test-specific JWTs, and keeping Minimal API handlers easy to invoke directly.

They are not meant as a prescribed sequence. Each article focuses on a different testing problem and on deciding which parts of the application infrastructure are worth including in the test.

The common theme is keeping tests focused on behavior while still involving enough of the real ASP.NET Core pipeline to make the result meaningful.

Explore this topic