Provider Extensibility and registry logic

[cwinland]

Description:
Implement extensible provider architecture. Key components:

• IMockingProvider abstraction
• MockingProviderRegistry for one-line provider swaps
• Support for developer-supplied custom providers
• Default reflection-based provider with no external dependencies

[cwinland]

Context

FastMoq currently assumes a single mocking provider implementation at runtime.
To make the framework provider‑agnostic and extensible, we need a registry and abstraction layer that allows:

• Multiple mocking providers to be registered.
• Switching providers at runtime or per test.
• Adding custom providers without modifying core code.

---

High‑Level Goals

• Define a provider interface (IMockingProvider) that all providers must implement.
• Create a registry (MockingProviderRegistry) to manage available providers.
• Allow default provider selection and per‑test overrides.
• Ensure all FastMoq features (constructor injection, verification, logging) work regardless of provider.

---

Proposed Structure

1. Provider Interface

public interface IMockingProvider
{
    object CreateMock(Type type);
    T CreateMock<T>() where T : class;
    void Verify<T>(Expression<Action<T>> expression) where T : class;
    // Additional provider-specific capabilities
}

2. Provider Registry

public static class MockingProviderRegistry
{
    private static readonly Dictionary<string, IMockingProvider> _providers = new();
    private static IMockingProvider _defaultProvider;

    public static void Register(string name, IMockingProvider provider, bool setAsDefault = false)
    {
        _providers[name] = provider;
        if (setAsDefault) _defaultProvider = provider;
    }

    public static IMockingProvider Get(string name) => _providers[name];
    public static IMockingProvider Default => _defaultProvider;
}

3. Integration with Mocker

• Mocker resolves mocks via MockingProviderRegistry.Default unless overridden.
• Tests can call MockingProviderRegistry.Register("Moq", new MoqProvider(), true) or similar.

---

Example Usage

// Register providers at test startup
MockingProviderRegistry.Register("Moq", new MoqProvider(), setAsDefault: true);
MockingProviderRegistry.Register("NSubstitute", new NSubstituteProvider());

// Use default provider
var mock = Mocker.CreateMock<IMyService>();

// Switch provider for a specific test
MockingProviderRegistry.Register("NSubstitute", new NSubstituteProvider(), setAsDefault: true);

---

Benefits

• Extensible: Add new providers without touching core code.
• Flexible: Switch providers per test or globally.
• Future‑proof: Supports community‑contributed providers.

---

Next Steps:

• Implement IMockingProvider and MockingProviderRegistry.
• Update Mocker to resolve mocks through the registry.
• Add tests for multiple provider scenarios.
• Document provider creation in Milestone 5.

[cwinland]

Summary of what must change:

1. Package / project split

• FastMoq.Core: no reference to Moq; contains Mocker, registry, abstractions (IMockingProvider, IMock, adapters, logger capture, reflection fallback provider).
• FastMoq.Provider.Moq (new): references Moq; implements IMockingProvider + adapters + Moq‑compat extension helpers.
• (Optional) FastMoq.Provider.Reflection: lightweight default “no external deps” provider (DispatchProxy / DynamicProxy style) for basic auto‑injection & invocation recording.
• Transitional meta package FastMoq (current id) can depend on Core + Moq provider for a deprecation period; later point it only depends on Core.

2. Public API cleanup

• Remove all direct return types / parameters of Moq.Mock or Mock from FastMoq.Core public surface.
• Replace with IMock / IMock. Keep legacy methods in a separate Moq extensions class inside the Moq provider assembly:
  public static Mock AsMoq(this IMock mock)
  public static Mock GetMoq(this Mocker mocker)
• Mark any remaining Moq‑typed members [Obsolete] in a “compat” partial class compiled only in the Moq provider package.

3. Internal refactor

• Mocker.mockCollection -> List where MockModel holds IMock (not Moq.Mock).
• All places using .Setup(), .Verify(), .Protected(), .CallBase, .Setups count, Switch to provider methods (Setup abstraction, Verify method, capability flags).
• Logger interception: replace Moq setups with a provider‑agnostic TestLogger injected via AddType<ILogger> unless a provider advertises SupportsLoggerInterception.

4. EF Core support

• Current DbContextMock derives from Moq.Mock. Replace with composition:
  class DbContextMockHandle { public IMock Mock; public TContext Instance => Mock.Instance; ... }
• DbSet mocking: implement provider‑agnostic helpers (if provider can intercept virtuals) OR supply in‑memory DbSet builder independent of mocking provider.

5. Provider registry

• Thread‑safe (ConcurrentDictionary) + AsyncLocal override stack.
• Mocker consults MockingProviderRegistry.Current (scoped) or Default at mock creation.

6. Reflection fallback provider

• Creates proxy instances (virtual members only) returning defaults, records invocations, optional loose verification (count only).
• Capabilities flags identify unsupported features so Mocker can skip SetupAllProperties / Protected.

7. Times / verification abstraction

• TimesSpec struct (Exactly / AtLeast / AtMost / Never) mapped by providers.
• Moq adapter converts to Moq.Times; other providers to their own patterns.

8. Migration path
   Phase 1: Add abstractions + Moq adapter; core still builds with Moq (no behavior change).
   Phase 2: Move Moq code out; core no longer references Moq; meta package depends on Moq provider; mark legacy APIs obsolete.
   Phase 3: Remove meta package Moq dependency; docs instruct: dotnet add package FastMoq.Provider.Moq.
   Phase 4: Remove obsolete members.

9. Packaging / nuspec

• Remove Moq from FastMoq.Core and FastMoq.Web dependencies.
• New package FastMoq.Provider.Moq includes Moq dependency and README snippet:
  MockingProviderRegistry.Register("moq", new MoqProvider(), setAsDefault: true);

10. Developer experience

• Default install (Core only) still works for constructor auto‑injection with reflection provider.
• To use Moq features (strict, protected, fine-grained verification) they add the provider package explicitly.

11. Breaking risk mitigation

• Provide analyzer (optional later) warning when direct Mock APIs are used without adding the Moq provider package.
• Maintain extension helpers for a deprecation window.

12. Blazor impact

• Component test base just calls Mocks.GetObject / GetMockAdapter — unaffected once mocks are provider‑agnostic.

Action checklist:

• Add abstractions (IMockingProvider, IMock, capabilities, TimesSpec, MockCreationOptions).
• Introduce registry with scoped override (Push/Dispose).
• Refactor Mocker & MockModel to use abstractions.
• Implement Reflection provider (basic).
• Extract existing Moq logic into FastMoq.Provider.Moq (adapters + SetupAllProperties emulation call).
• Add compatibility extensions returning Moq.Mock.
• Remove Moq package reference from core csproj.
• Update README / docs (installation matrix).
• Add contract tests executing same suite against both providers.

Once done you can safely remove Moq from the core; consumers choose the provider they want.