Migrate Static To Wrapper

Migrate Static to Wrapper

Perform mechanical, codemod-style replacement of static dependency call sites with calls to injected wrapper interfaces or built-in abstractions. Operates on a bounded scope (single file, project, or namespace) so migrations can be done incrementally.

When to Use

• After wrappers have been generated (via generate-testability-wrappers) or built-in abstractions identified
• Migrating DateTime.UtcNow → TimeProvider.GetUtcNow() across a project
• Migrating File.* → IFileSystem.File.* across a namespace
• Adding constructor injection for the new abstraction to affected classes
• Making a static utility class testable by adding an ambient seam (Step 3) while its existing call sites keep compiling unchanged
• Incremental migration: one project or namespace at a time
• Updating affected tests with fakes when the requested migration names the replacement abstraction

When Not to Use

• No wrapper or abstraction exists yet and one must be designed from scratch (use generate-testability-wrappers first). A built-in abstraction such as TimeProvider or IFileSystem always counts as existing.
• The user wants to detect statics, not migrate them (use detect-static-dependencies)
• Migrating between test frameworks (use the appropriate migration skill)
• The user primarily asks for a deterministic behavior test and has not selected the production seam (use testability-obstacle)

A class that is static, or a project with no DI container, is not a reason to skip this skill — that is exactly what the ambient seam in Step 3 is for. Use it whenever the call sites must keep compiling unchanged.

Inputs

Workflow

Non-negotiable migration boundaries

• Missing abstraction means stop. If the named interface/package is absent and the request only authorizes call-site replacement, do not add a package, invent a local lookalike interface, or edit production code. Report the exact missing prerequisite and the authorization needed to continue.
• One source read stays one replacement read. Do not hoist or coalesce calls, even when sharing a captured timestamp looks cleaner.
• The requested scope is exhaustive and exclusive. Replace every named call in scope and no adjacent member or file.
• Repository-backed requests require repository work. Start by discovering files from the current workspace. Do not claim the repository is unavailable or ask the user for a path or file contents until workspace-relative discovery found no target. Do not say work was implemented unless the diff proves it.
• Discovered workspace files must be completed in this turn when permitted. Use a host-native shell reader (sed/cat or Get-Content) only after a confirmed reader availability, transport, or path-normalization failure and only after verifying the canonical path remains inside the current workspace. Stop on content-exclusion, permission/policy, workspace-boundary, or unknown read failures. Use a shell edit fallback only for a confirmed editor availability, transport, or path-normalization failure, never for a stale context, concurrent change, permission/policy denial, or path-boundary error. Before fallback, resolve the canonical path inside the current workspace, freshly read the file, and require an anchored replacement with the expected old text and exact match count; abort if either changed. Then re-open the file, inspect the diff, and validate. Do not ask the user to paste a readable discovered file or report a proposed patch as completed work.

Step 1: Verify prerequisites

Before modifying any code:

1. Confirm the wrapper/abstraction exists: Check that the interface or built-in abstraction is available in the project. For TimeProvider, verify the target framework is .NET 8+ or Microsoft.Bcl.TimeProvider is referenced. For System.IO.Abstractions, verify the NuGet package is referenced. A package that could provide an abstraction is not the same as an abstraction already available to this project.

2. Confirm production composition exists: Check Program.cs, Startup.cs, or manual construction sites. If package, wrapper, or registration work is missing, add it only when the user explicitly authorized those dependency/composition changes. Otherwise stop before editing call sites and report the exact prerequisite; do not turn a scoped migration into first-time abstraction design.

3. Identify all files in scope: List the .cs files that will be modified. Exclude test projects, obj/, bin/, and generated code.

4. Lock and count the member set before editing: Use the exact member named by the user, or infer the smallest unambiguous set from the request and discovered call sites. Record that set, then search every member and capture the file/line inventory. Do not change the set mid-edit or infer counts from a partial read.

Step 2: Plan the migration for each file

Migrate exactly what was asked — nothing adjacent. If the user named a member (DateTime.UtcNow), migrate only that member and leave siblings such as DateTime.Now untouched. If the user named files, do not touch other files. Preserve a call site whose comment or name marks it as deliberate (e.g. // intentional local time) unless the user explicitly names that site and requests a semantics-preserving migration. List everything you deliberately left alone under "Remaining (out of scope)" so the user can ask for it in a follow-up; suggesting is fine, silently widening the scope is not.

For each file containing the static pattern, determine:

1. Which class(es) contain the call sites — identify the class declarations
2. Whether the class already has the dependency injected — check constructors for existing TimeProvider, IFileSystem, etc. parameters
3. The replacement expression for each call site

Replacement mapping

Apply the same pattern for other members in each category.

Preserve DateTimeKind — this is the most common silent regression. TimeProvider.GetUtcNow() / GetLocalNow() return a DateTimeOffset. Converting back to DateTime must keep the original Kind, otherwise you introduce a behavioral change even though the code still compiles:

• DateTime.UtcNow has Kind == Utc → use .UtcDateTime (not .DateTime, which yields Kind == Unspecified).
• DateTime.Now has Kind == Local → use .LocalDateTime (not .DateTime).
• When a call site consumes a DateTimeOffset directly (a field/parameter/return already typed DateTimeOffset), drop the .UtcDateTime/.LocalDateTime suffix and assign the DateTimeOffset as-is — don't force it back through DateTime.

Match the target member's type: if the surrounding field/property is DateTime, keep it DateTime (via the Kind-correct property above); do not change it to DateTimeOffset as part of a "mechanical" migration — that is a design change, not a delegation.

Preserve the number, order, and location of reads as well as the value type. Replace each original clock read in place with one provider read. Do not hoist, cache, or coalesce two reads into a shared now local, even when they are in the same object initializer or method. Two consecutive DateTime.UtcNow calls could observe different instants; making CreatedAt and ExpiresAt derive from one captured value is a behavior change, not a mechanical migration. Reuse a value only when the original code already captured and reused one.

Step 3: Add constructor injection

Add the new dependency following the class's existing pattern:

• Primary constructor (C# 12+): Add parameter to primary constructor: public class OrderProcessor(ILogger<OrderProcessor> logger, TimeProvider timeProvider)
• Traditional constructor: Add private readonly field + constructor parameter, matching the existing field naming convention (_camelCase or m_camelCase)

Static classes: use ambient context (no constructor injection)

A static class with only static members cannot receive constructor injection — adding an instance constructor or instance field would break it. Do not convert it to a non-static class just to inject the dependency; that changes its design and every call site. Instead, apply a scoped ambient seam that defaults to the real implementation and can be overridden without leaking process-global state.

When the user wants to keep the class static, the ambient seam below is the answer — present it as the solution and implement it directly. Do not hedge by offering "convert it to a non-static class" or "pass TimeProvider as a method parameter" as co-equal alternatives; those change the class's design or public API and are not what was asked. Lead with the seam, then note the parallelism trade-off.

public static class TimestampFormatter
{
  private static readonly AsyncLocal<TimeProvider?> s_clock = new();

  private static TimeProvider Clock => s_clock.Value ?? TimeProvider.System;

  public static string Now() => Clock.GetUtcNow().ToString("O");

  public static IDisposable OverrideClock(TimeProvider clock)
  {
      ArgumentNullException.ThrowIfNull(clock);
      var previous = s_clock.Value;
      s_clock.Value = clock;
      return new Scope(() => s_clock.Value = previous);
  }

  private sealed class Scope : IDisposable
  {
      private Action? _restore;

      public Scope(Action restore)
      {
          _restore = restore;
      }

      public void Dispose() => Interlocked.Exchange(ref _restore, null)?.Invoke();
  }
}

• Production reads TimeProvider.System whenever no override is active; no startup mutation is required.
• Tests create a fresh fake/provider per async flow and dispose the returned scope. Nested disposal restores the outer provider.
• AsyncLocal<T> keeps independently established test flows isolated across await. Do not store a mutable stack/list in the slot or mutate one fake inherited by multiple child flows.
• Add focused tests for substitution, nested restoration, and parallel async isolation. A build-only check does not prove this seam.
• The same shape works for other statics (IFileSystem, custom wrappers): store the abstraction value in AsyncLocal<T>, default to the real implementation, and restore the previous value from the scope.