domains / families / software-engineering / migrate-static-to-wrapper

migrate-static-to-wrapper

separate

ALWAYS USE when asked to migrate, replace, or make testable existing C# static calls with a named wrapper or built-in abstraction: DateTime.UtcNow/Now or DateTimeOffset.UtcNow to TimeProvider/IClock, File.* to IFileSystem or an existing store such as ITextFileStore, and Environment.* to an existing reader such as IEnvironmentReader. Covers scoped files/projects, constructor injection, replacing temp-file or process-environment tests with fakes, "already registered" abstractions, and static classes whose callers/signatures must stay unchanged. Preserves DateTimeKind and call count. DO NOT USE for finding statics (detect-static-dependencies), choosing/designing a new wrapper (generate-testability-wrappers), behavior tests with no chosen seam (testability-obstacle), or test-framework migration.

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
• Incremental migration: one project or namespace at a time
• Updating affected tests with fakes when the requested migration names the

When not to use

• No wrapper or abstraction exists yet and one must be designed from scratch (use `generate-testability-wrappers` first).
• 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

Skill page

Source