How ASP.NET Core Tests Are Organized in the dotnet/aspnetcore Repository

The ASP.NET Core test suite follows a component-centric layout where each framework component under src/<Component>/ contains its own test subfolder with xUnit-based .Tests.csproj projects, unit test classes using [Fact] attributes, and dedicated functional test directories like FunctionalTests and WebSites.

The dotnet/aspnetcore repository houses thousands of ASP.NET Core tests that validate everything from low-level server implementations to high-level MVC abstractions. Understanding this organization is essential for contributors who need to navigate the codebase, isolate failures, and run targeted test suites during development. The repository mirrors its modular architecture in the test layout, ensuring that every major component maintains its own isolated testing boundary.

Component-Centric Directory Layout

The ASP.NET Core tests adopt a directory structure that maps directly to the framework's source tree. Each major component—such as Hosting, Kestrel, SignalR, or MVC—resides under src/<Component>/ and contains a dedicated test subfolder adjacent to its implementation code.

This co-location strategy ensures that unit tests remain closely coupled with the source they validate while maintaining separation from integration scenarios. For example, the TestHost component stores its tests in src/Hosting/TestHost/test/, Kestrel server tests live in src/Servers/Kestrel/test/, and SignalR server tests reside in src/SignalR/server/SignalR/test/. This predictable pattern repeats across the repository, allowing developers to locate relevant tests by following the component hierarchy.

Test Project Structure and Naming Conventions

Project Files and Dependencies

Inside each test folder, a test project file ending with .Tests.csproj defines the test assembly and its dependencies. These files reference the component's source project along with testing dependencies such as xUnit and Microsoft.AspNetCore.TestHost.

Notable project locations include:

• src/Hosting/TestHost/test/Microsoft.AspNetCore.TestHost.Tests.csproj
• src/Servers/Kestrel/test/Microsoft.AspNetCore.Server.Kestrel.Tests.csproj
• src/SignalR/server/SignalR/test/Microsoft.AspNetCore.SignalR.Tests/Microsoft.AspNetCore.SignalR.Tests.csproj
• src/Mvc/test/Mvc.FunctionalTests/Microsoft.AspNetCore.Mvc.FunctionalTests.csproj

Test Class Naming Patterns

Test classes are implemented in .cs files that follow strict naming conventions. Class names typically end with the suffix Tests or Test, such as TestServerTests found in src/Hosting/TestHost/test/TestServerTests.cs. These classes utilize xUnit attributes for discovery:

• [Fact] for standard unit test methods
• [Theory] for parameterized tests with inline or external data sources

Unit Tests vs. Functional Tests

Unit Test Placement

Unit tests reside directly within the component's test folder alongside the project file. These tests validate individual classes and methods in isolation, frequently using the TestServer class to simulate HTTP pipelines without network overhead or port binding.

Example from src/Hosting/TestHost/test/TestServerTests.cs:

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.TestHost;
using Xunit;

public class TestServerTests
{
    [Fact]
    public async Task GenericCreateAndStartHost_GetTestServer()
    {
        using var host = await new HostBuilder()
            .ConfigureWebHost(webBuilder => webBuilder.UseTestServer().Configure(app => { }))
            .StartAsync();

        var response = await host.GetTestServer().CreateClient().GetAsync("/");
        Assert.Equal(HttpStatusCode.NotFound, response.StatusCode);
    }
}

Functional and Integration Test Organization

Functional tests occupy dedicated subfolders that house complete application setups for end-to-end validation. The repository uses directory names such as FunctionalTests, WebSites, and testassets to segregate these comprehensive scenarios from fast unit tests.

For instance, the MVC framework organizes its functional tests under src/Mvc/test/Mvc.FunctionalTests/, while supporting test websites live in companion directories to provide realistic deployment targets. These tests exercise multi-component interactions, middleware pipelines, and actual HTTP client-server communication patterns.

Shared Test Infrastructure

Common utilities and diagnostic helpers live in centralized locations to prevent duplication across component test suites. The src/Testing/ directory contains reusable infrastructure such as TestServer, TestDiagnosticListener, and specialized host builders.

The project file src/Testing/test/Microsoft.AspNetCore.InternalTesting.Tests.csproj packages these shared components, which individual test projects reference via standard project references. This architecture ensures consistent testing capabilities—from in-memory hosting to log capture—across all ASP.NET Core tests without requiring each component to reimplement boilerplate infrastructure.

CI Integration and Local Execution

The repository's continuous integration pipelines automatically discover and execute all ASP.NET Core tests by enumerating *.Tests.csproj files under src/**/test paths. This glob-based discovery ensures that new test projects following the naming convention automatically participate in build validation without manual registration in CI scripts.

Developers can execute isolated test suites locally using targeted dotnet test commands:

dotnet test src/Hosting/TestHost/test
dotnet test src/Servers/Kestrel/test
dotnet test src/Mvc/test/Mvc.FunctionalTests

This modular execution strategy supports rapid feedback loops during component-specific development while maintaining comprehensive coverage validation for the entire framework.

Summary

• The dotnet/aspnetcore repository organizes ASP.NET Core tests using a component-centric layout that mirrors the src/ directory structure, with each major framework area maintaining its own test subfolder.

• Test project files use the .Tests.csproj suffix and reside in component test folders alongside C# test classes that typically end with the Tests suffix.

• Unit tests utilizing xUnit's [Fact] and [Theory] attributes live directly in the test folder, while functional tests occupy dedicated subdirectories such as FunctionalTests and WebSites.

• Shared testing infrastructure including TestServer and TestDiagnosticListener lives in src/Testing/ and is referenced by multiple component test projects to ensure consistency.

• CI pipelines automatically discover test projects by searching for *.Tests.csproj files under src/**/test, enabling seamless integration of new test suites without configuration updates.

Frequently Asked Questions

Where are unit tests located in the ASP.NET Core repository?

Unit tests are located in the test subfolder of each component directory under src/. For example, Hosting tests reside in src/Hosting/TestHost/test/ and Kestrel tests are in src/Servers/Kestrel/test/. Each folder contains a .Tests.csproj file and C# test classes using xUnit attributes like [Fact] to validate specific implementation details.

What is the difference between unit tests and functional tests in dotnet/aspnetcore?

Unit tests validate individual classes and methods in isolation, often using TestServer from Microsoft.AspNetCore.TestHost to simulate HTTP contexts without actual network I/O. Functional tests validate end-to-end scenarios and multi-component interactions, residing in dedicated subfolders such as FunctionalTests, WebSites, or testassets that contain complete application configurations and realistic middleware pipelines.

How do I run only the tests for a specific ASP.NET Core component?

Use the dotnet test command targeting the specific test project path. Execute dotnet test src/Hosting/TestHost/test to run only TestHost tests, or dotnet test src/Mvc/test/Mvc.FunctionalTests for MVC functional validation. This targeting prevents unnecessary execution of unrelated test suites and significantly reduces feedback time during component-specific development.

What shared testing utilities are available for ASP.NET Core tests?

The repository provides centralized testing infrastructure in the src/Testing/ directory, including TestServer for in-memory HTTP testing, TestDiagnosticListener for capturing diagnostic events, and various host builder utilities. These shared components are packaged in Microsoft.AspNetCore.InternalTesting.Tests.csproj and referenced by individual component test projects to provide consistent, reusable testing capabilities across the entire framework.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}