# What Types of Tests Are Found in the AspNetCore Test Directory?

> Explore the AspNetCore test directory for unit, integration, functional, conformance, and performance tests. Learn how xUnit and TestHost ensure code quality and protocol compliance.

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

---

**The aspnetcore repository organizes automated tests into unit, integration, functional, conformance, and performance categories, utilizing xUnit and Microsoft.AspNetCore.TestHost to validate everything from isolated methods to full protocol compliance.**

The `dotnet/aspnetcore` repository maintains a comprehensive validation suite distributed across component-specific `test` directories within the `src` tree. These **tests found in the aspnetcore test directory** structures verify every layer of the framework, from individual class methods to complete HTTP pipeline simulations. Each major component—from Data Protection to WebSockets—contains its own test folder housing xUnit-based suites, shared assets, and configuration files.

## Unit Tests

**Unit tests** provide fast, isolated feedback by exercising a single class or method without external dependencies. These tests reside in component-specific test folders and leverage the **xUnit** testing framework with the `[Fact]` attribute to define test cases.

In [`src/DataProtection/DataProtection/test/Microsoft.AspNetCore.DataProtection.Tests/Repositories/RegistryXmlRepositoryTests.cs`](https://github.com/dotnet/aspnetcore/blob/main/src/DataProtection/DataProtection/test/Microsoft.AspNetCore.DataProtection.Tests/Repositories/RegistryXmlRepositoryTests.cs), unit tests validate XML repository implementations for Windows registry-based key storage. These tests instantiate the repository directly, invoke methods, and assert against expected outcomes without spinning up a web server.

```csharp
public class SimpleMathTests
{
    [Fact]
    public void Add_ReturnsCorrectSum()
    {
        var result = SimpleMath.Add(2, 3);
        Assert.Equal(5, result);
    }
}

```

## Integration and Functional Tests

**Integration tests** verify interactions between multiple components by spinning up a minimal ASP.NET Core host using **TestServer** or **WebApplicationFactory<T>**. These tests issue real HTTP requests against the in-process server to validate middleware pipelines, routing, and authentication flows.

The functional test suites in `src/DefaultBuilder/test/Microsoft.AspNetCore.FunctionalTests/` demonstrate this approach, often utilizing shared assets like `testCert.pfx` for HTTPS scenario validation. These tests ensure that middleware components integrate correctly when composed into a realistic application pipeline.

```csharp
public class MiddlewareIntegrationTests : IClassFixture<WebApplicationFactory<Startup>>
{
    private readonly HttpClient _client;
    public MiddlewareIntegrationTests(WebApplicationFactory<Startup> factory) =>
        _client = factory.CreateClient();

    [Fact]
    public async Task GetRoot_ReturnsHelloWorld()
    {
        var response = await _client.GetAsync("/");
        response.EnsureSuccessStatusCode();
        var content = await response.Content.ReadAsStringAsync();
        Assert.Equal("Hello World!", content);
    }
}

```

## Conformance Tests

**Conformance tests** validate protocol-level compliance against external specifications such as WebSocket RFCs and HTTP/2 standards. These specialized integration tests ensure the implementation adheres strictly to wire protocols expected by browsers and third-party clients.

The `src/Middleware/WebSockets/test/ConformanceTests/` directory contains the Autobahn test suite assets, including `AutobahnTestApp` and supporting resources. These tests verify that the WebSocket middleware correctly handles frame masking, fragmentation, and close handshakes according to RFC 6455.

```csharp
public class WebSocketConformanceTests : IClassFixture<WebSocketTestServer>
{
    private readonly WebSocketTestServer _server;
    public WebSocketConformanceTests(WebSocketTestServer server) => _server = server;

    [Fact]
    public async Task Echo_ValidFrame_ReturnsSamePayload()
    {
        using var ws = await _server.ConnectAsync();
        var payload = Encoding.UTF8.GetBytes("ping");
        await ws.SendAsync(new ArraySegment<byte>(payload), WebSocketMessageType.Text, true, CancellationToken.None);

        var buffer = new byte[1024];
        var result = await ws.ReceiveAsync(new ArraySegment<byte>(buffer), CancellationToken.None);
        var echoed = Encoding.UTF8.GetString(buffer, 0, result.Count);
        Assert.Equal("ping", echoed);
    }
}

```

## Component and End-to-End Tests

**Component tests** focus on Razor and Blazor rendering lifecycles, JavaScript interop, and static asset delivery. These tests validate the component model independently from the full HTTP stack while still exercising the rendering pipeline.

The `src/Components/test/testassets/BasicTestApp/` directory contains assets used to validate component behavior, including [`wwwroot/js/testmodule.js`](https://github.com/dotnet/aspnetcore/blob/main/wwwroot/js/testmodule.js) for JavaScript interop scenarios. These tests ensure that components render correctly across different hosting models and that static resources are properly integrated.

## Performance and Benchmark Tests

While distributed across the `src/Benchmarks` tree, **performance tests** form a critical part of the aspnetcore testing strategy. These microbenchmarks measure throughput, latency, and allocation patterns for hot paths such as Kestrel's HTTP parser and routing middleware. BenchmarkDotNet typically drives these suites, providing statistical rigor for performance regression detection.

## Shared Test Resources and CI Configuration

Test directories contain more than source code—they house **shared resources** required for realistic scenarios. These include:

- **Security certificates**: `src/Middleware/HttpsPolicy/sample/testCert.pfx` and similar `.pfx` files enable HTTPS middleware testing without relying on system certificate stores.
- **Configuration files**: [`src/DataProtection/StackExchangeRedis/test/testconfig.json`](https://github.com/dotnet/aspnetcore/blob/main/src/DataProtection/StackExchangeRedis/test/testconfig.json) provides connection strings for integration tests against Redis-backed data protection keys.
- **Test matrices**: [`eng/test-configuration.json`](https://github.com/dotnet/aspnetcore/blob/main/eng/test-configuration.json) defines the CI test matrix, specifying which test projects execute against specific runtime versions and operating systems.

## Summary

- **Unit tests** in paths like `src/DataProtection/DataProtection/test/` validate isolated classes using xUnit `[Fact]` methods.
- **Integration tests** leverage `WebApplicationFactory<T>` and `TestServer` to spin up in-process hosts for realistic HTTP pipeline testing.
- **Conformance tests** verify protocol compliance using external test harnesses such as Autobahn for WebSockets.
- **Component tests** exercise Razor and Blazor rendering with assets like `BasicTestApp`.
- **Performance benchmarks** reside in `src/Benchmarks` and measure critical path throughput.
- **Shared resources** including certificates and JSON configurations support cross-cutting test scenarios across all test directories.

## Frequently Asked Questions

### What testing framework does the aspnetcore repository use?

The aspnetcore repository uses **xUnit** as its primary testing framework. Test classes utilize the `[Fact]` attribute to denote test methods, and the xUnit runner executes all tests across the repository's various `test` directories.

### How do integration tests spin up a web server without external processes?

Integration tests use **Microsoft.AspNetCore.TestHost** to create an in-process server. Classes implement `IClassFixture<WebApplicationFactory<T>>` to gain access to an `HttpClient` that communicates directly with the test server, eliminating network overhead while preserving realistic request processing.

### Where are protocol conformance tests located in the repository?

Protocol conformance tests reside in component-specific conformance folders, such as `src/Middleware/WebSockets/test/ConformanceTests/`. These directories contain resources for external test harnesses like Autobahn, which validate RFC compliance for WebSocket implementations.

### What is the purpose of the eng/test-configuration.json file?

The [`eng/test-configuration.json`](https://github.com/dotnet/aspnetcore/blob/main/eng/test-configuration.json) file serves as the central CI configuration matrix. It defines which test projects run, on which platforms, and against which runtime versions, ensuring comprehensive coverage across Windows, Linux, and macOS environments for all tests in the aspnetcore repository.