Generate Testability Wrappers

Generate Testability Wrappers

Generate wrapper interfaces, default implementations, and DI service registration code for untestable static dependencies. For statics that already have .NET built-in abstractions (TimeProvider, IHttpClientFactory), guide adoption of the built-in. For statics without built-in alternatives, generate custom minimal wrappers.

When to Use

• After running detect-static-dependencies and identifying which statics to wrap
• When the user asks to make a class testable by replacing statics with injected abstractions
• When adopting TimeProvider (.NET 8+) or System.IO.Abstractions
• When creating a custom wrapper for Environment.*, Console.*, or Process.*
• When a released static API needs an ambient seam because signatures cannot change

When Not to Use

• The user wants to find statics first (use detect-static-dependencies)
• The user wants to bulk-replace call sites (use migrate-static-to-wrapper)
• The static is already behind an interface

If the target already consumes an injected interface or built-in abstraction, stop: do not add a second wrapper, project, registration, or test around that seam.

A missing DI package does not by itself force an ambient seam. For an instantiable class, prefer constructor injection and compose it explicitly or show the requested registration. Use Step 5 when the API is static and its signatures must stay static, or when the user explicitly forbids caller construction/DI changes.

Inputs

Workflow

Step 1: Determine the abstraction strategy

Based on the category and target framework:

The table picks which abstraction. How it reaches the code under test is a separate axis:

• instantiable class: constructor injection, even if current callers compose the object manually;
• existing container: add compile-ready registration following its conventions;
• public static API/signatures that cannot change: Step 5's ambient seam.

Check for a host builder, IServiceCollection, existing registrations, and construction sites. Do not infer "must remain static" merely because the project currently has no container.

Step 2: Generate built-in abstraction adoption (Time, HTTP)

TimeProvider (.NET 8+)

No wrapper code needed. Complete all four parts: production registration, constructor injection, a FakeTimeProvider test, and the testing package.

1. Register in DI:

builder.Services.AddSingleton(TimeProvider.System);

2. Inject into classes:

public class OrderProcessor(TimeProvider timeProvider)
{
    public bool IsExpired(Order order)
        => timeProvider.GetUtcNow() > order.ExpiresAt;
}

3. Test with FakeTimeProvider:

// Requires Microsoft.Extensions.TimeProvider.Testing NuGet
var fakeTime = new FakeTimeProvider(new DateTimeOffset(2026, 1, 15, 0, 0, 0, TimeSpan.Zero));
var processor = new OrderProcessor(fakeTime);
fakeTime.Advance(TimeSpan.FromDays(1));
Assert.True(processor.IsExpired(order));

The assertion must prove a time-dependent result after the fake is pinned or advanced. Merely constructing FakeTimeProvider is not a test. When the project has no container but the target is an instantiable class, inject TimeProvider anyway and show explicit production construction with TimeProvider.System; do not replace it with a custom static clock.

Before calling the adoption complete, verify the repository contains or the answer supplies every required artifact: the testing package reference, the production composition/registration, every affected constructor call, and a runnable fake-time test. A code fragment that omits one of those integration points is guidance, not a completed adoption.

TimeProvider (pre-.NET 8)

Guide: install Microsoft.Bcl.TimeProvider NuGet. Same API as above.

IHttpClientFactory

No wrapper code needed. Register a typed client via builder.Services.AddHttpClient<MyService>() and inject HttpClient directly into the class constructor. Preserve cancellation by passing the caller's token to the HTTP operation.

For tests, provide a complete fake HttpMessageHandler whose SendAsync returns a deterministic HttpResponseMessage, construct HttpClient with that handler, and exercise the typed client without network access. Compile and run the focused test when the task asks for implementation; do not stop at a schematic handler method.

When production uses a typed-client registration, test that same registration pipeline: configure its primary handler in ServiceCollection, resolve the typed client, and call it. A test that manually constructs HttpClient proves the class but not the DI registration the task asked to adopt.

Step 3: Generate custom wrappers (Environment, Console, Process)

For categories without built-in abstractions, follow this template:

Interface — define the minimal surface

Only include methods that were actually detected in the codebase. Do NOT generate a wrapper for every possible member — wrap only what is used.

Prefer a stateless operation-shaped interface. For example, if a caller only needs to start a process, wait, and return its exit code, expose one Run operation rather than a stateful wrapper that leaks Process lifecycle.

namespace <Namespace>;

/// <summary>
/// Abstraction over <static class> for testability. 
/// </summary>
public interface I<WrapperName>
{
    // One method per detected static call
    <return type> <MethodName>(<parameters>);
}

Default implementation — delegate to the real static

namespace <Namespace>;

/// <summary>
/// Default implementation that delegates to <static class>.
/// </summary>
public sealed class <WrapperName> : I<WrapperName>
{
    public <return type> <MethodName>(<parameters>)
        => <StaticClass>.<Method>(<arguments>);
}

DI registration

// In Program.cs or Startup.cs:
builder.Services.AddSingleton<I<WrapperName>, <WrapperName>>();

Treat registration as a deliverable, not a sentence in the summary. Add it to the repository's existing registration surface when one exists. Otherwise show the exact compile-ready statement and identify where the caller should place it. Stateless delegating wrappers are singleton; if state must be retained, explain why a shorter lifetime is required.

Step 4: Generate file system wrapper adoption

Prefer the established System.IO.Abstractions NuGet package over custom wrappers:

1. Install the package:

dotnet add package System.IO.Abstractions

2. Register in DI:

builder.Services.AddSingleton<IFileSystem, FileSystem>();

3. Inject IFileSystem into classes:

public class ConfigLoader(IFileSystem fileSystem)
{
    public string LoadConfig(string path)
        => fileSystem.File.ReadAllText(path);
}

4. Test with MockFileSystem:

dotnet add <TestProject> package System.IO.Abstractions.TestingHelpers

var mockFs = new MockFileSystem(new Dictionary<string, MockFileData>
{
    { "/config.json", new MockFileData("{\"key\": \"value\"}") }
});
var loader = new ConfigLoader(mockFs);
Assert.Equal("{\"key\": \"value\"}", loader.LoadConfig("/config.json"));

Package-first adoption is exclusive: add both package references, use IFileSystem in production, register or explicitly compose FileSystem, and seed MockFileSystem before exercising the consumer. Do not also generate a second custom filesystem interface, and do not present an unseeded mock whose test could pass without proving the requested read/write behavior.