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

> Discover how ASP.NET Core tests are organized in the dotnet/aspnetcore repository. Learn about component-centric layout, xUnit tests, and functional test structures.

- Repository: [.NET Platform/aspnetcore](https://github.com/dotnet/aspnetcore)
- Tags: internals
- Published: 2026-08-01

---

**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`](https://github.com/dotnet/aspnetcore/blob/main/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`](https://github.com/dotnet/aspnetcore/blob/main/src/Hosting/TestHost/test/TestServerTests.cs):

```csharp
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:

```bash
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.