Shared Test Infrastructure Abstractions

In this lesson, you will learn how to reduce boilerplate in your test suite by creating reusable infrastructure abstractions that encapsulate complex setup logic.

As your test suite grows, you likely find yourself repeating the same WebApplicationFactory configurations, Testcontainers setups, and authentication stubs across multiple test classes. If you update your database schema or change an authentication provider, you end up hunting through dozens of files to apply fixes. "Shared Test Infrastructure Abstractions" solve this by shifting that logic into a centralized, reusable "Test Harness."

The Base Integration Test Class

Rather than configuring your environment inside every test file, create a base class that manages the heavy lifting. This class acts as a single point of entry for your shared dependencies.

public abstract class IntegrationTestBase : IClassFixture<CustomWebApplicationFactory>
{
    protected readonly HttpClient Client;
    protected readonly CustomWebApplicationFactory Factory;

    protected IntegrationTestBase(CustomWebApplicationFactory factory)
    {
        Factory = factory;
        Client = factory.CreateClient();
    }

    // A shared abstraction for authenticated requests
    protected void AuthenticateAsUser(string userId) 
    {
        // Custom logic to inject claims/headers into the HttpClient
    }
}

Why Abstraction Matters

By abstracting the infrastructure, you create a "domain-specific" language for your tests. Your specific test classes should focus on the behavior being tested (e.g., "Can I create an order?"), not the plumbing (e.g., "How do I configure the Testcontainers connection string?").

When you need to perform common setup tasks—such as seeding a specific set of users or configuring a mocked HttpMessageHandler for third-party APIs—you can add helper methods to your base class or a specialized TestEnvironment helper object.

This approach ensures that your setup logic remains DRY (Don't Repeat Yourself). If you eventually migrate from one message queue provider to another, or swap your database container, you only modify the abstraction layer rather than every individual test case.

Key Takeaway: Build a centralized test harness to hide infrastructure plumbing, allowing your test classes to focus strictly on the business requirements of your application.