You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
his PR captures the FastMoq v4 release line relative to tag 3.0.0.
Compared to 3.0.0, FastMoq now moves from Moq-centric internals to a provider-first architecture, introduces a clearer package split, adds provider-neutral verification and scenario-building APIs, and expands the migration and release documentation needed to adopt the new model.
What changed
introduced provider-first abstractions and registry support through IMockingProvider, IMockingProviderCapabilities, IFastMock<T>, and MockingProviderRegistry
added the built-in reflection provider plus provider packages for Moq and NSubstitute
split the package layout so provider contracts live in FastMoq.Abstractions, EF/DbContext helpers live in FastMoq.Database, and provider-specific adapters live in FastMoq.Provider.*
moved DbContext-specific implementation details out of core while preserving the main FastMoq namespace call shape for end users
added provider-neutral verification and logging helpers, including Verify(...), VerifyLogged(...), and TimesSpec
added fluent scenario-building support with Scenario.With(...).When(...).Then(...).Verify(...)
replaced older coupled option flows with more explicit creation, invocation, and policy surfaces such as InstanceCreationFlags, InvocationOptions, BuiltInTypeResolutionFlags, and known-type registration support
narrowed compatibility behavior around Strict, kept MockOptional as an obsolete bridge, and moved Moq-specific HTTP compatibility helpers into FastMoq.Provider.Moq
expanded test coverage, executable examples, generated API documentation, migration guidance, and release notes for the v4 line
Breaking / migration notes
Strict is no longer the old all-in-one strictness switch; broader preset behavior should use the explicit preset APIs
strict IFileSystem behavior now stays enriched through FastMoq's built-in known-type pipeline instead of behaving like a raw empty Moq mock
older Moq-oriented HTTP setup helpers remain available for migration, but now come from FastMoq.Provider.Moq
existing suites can stay on the compatibility path, while new or actively refactored tests can move toward GetOrCreateMock(...), provider-neutral verification, and explicit provider selection
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+163-4Lines changed: 163 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ It wraps and extends mocking providers (currently Moq, with planned provider‑a
26
26
## 🧩 Coding Guidelines for Copilot
27
27
When generating code:
28
28
1.**Provider‑agnostic first**
29
-
- Use `IMockingProvider` methods for verification and mock creation.
29
+
- Use `IMockingProvider` methods for mock creation, setup, verification, etc.
30
30
- Only use Moq APIs inside `MoqProvider` or Moq‑specific test code.
31
31
2.**Reuse shared helpers**
32
32
- For component creation, always call `MockerConstructionHelper.CreateInstance`.
@@ -38,15 +38,38 @@ When generating code:
38
38
4.**Keep tests self‑contained**
39
39
- Use `Component` or `ComponentAs<T>()` from base classes.
40
40
- Prefer `Scenario.With(Component)` for new tests.
41
-
5.**Document new APIs**
42
-
- Add XML doc comments for public methods.
41
+
5.**Use proper using statements**
42
+
- Always add appropriate `using` statements at the top of files instead of fully qualified names.
43
+
- Example: Use `using System.Runtime;` then reference `AmbiguousImplementationException` instead of `System.Runtime.AmbiguousImplementationException`.
44
+
- Keep using statements organized and remove unused ones.
45
+
6.**Document new APIs**
46
+
- Add XML doc comments for all public, protected, and protected internal members you touch, including obsolete compatibility APIs that still appear in the public surface.
47
+
- When doing a documentation cleanup pass, finish by re-checking the touched file for any remaining undocumented public, protected, or protected internal members instead of assuming the patch caught them all.
43
48
- Include usage examples in Milestone docs.
49
+
7.**Static Analysis (Sonar) Compliance**
50
+
- Honor the rules in the "Static Analysis Rules" section below (S121, S122, S6608) when generating or refactoring code.
51
+
8.**Keep edits and updates task-bound**
52
+
- Progress updates must stay grounded in the current task, files, and findings. Do not insert speculative filler, unrelated examples, or generic brainstorming text.
53
+
- When a patch is too broad, split it into smaller targeted edits and complete local formatting cleanup before stopping.
54
+
- If you touch a large partial class, preserve the surrounding style and fix any indentation or malformed XML introduced in the edited region before considering the work done.
55
+
56
+
## 🔐 Static Analysis Rules (Sonar)
57
+
Apply these consistently in generated code (and prefer refactoring existing code toward them when touched):
58
+
- S121: Always use curly braces for control structures (`if/else`, `for`, `foreach`, `while`, `do`, `using`, `lock`, `switch` sections). No single-line implicit blocks.
59
+
- S122: One statement per line. Avoid multiple statements separated by semicolons on the same line. Keep declarations and executable statements clearly separated for readability.
60
+
- S6608: Prefer modern, clear C# constructs (pattern matching / expression forms) when it improves readability and safety, without sacrificing clarity. Do not apply micro-optimizations that reduce clarity. (If applicability is ambiguous, prefer the most readable form and add a brief comment if deviating.)
61
+
62
+
Notes:
63
+
- Do not introduce breaking changes solely to satisfy these rules. Apply them opportunistically or in newly generated code.
64
+
- If a rule conflicts with existing public API shape or widely-used patterns in the repository, prefer backward compatibility and add a TODO comment.
44
65
45
66
## 🚫 Avoid
46
67
- Hard‑coding Moq calls in shared/core code.
47
68
- Duplicating constructor resolution logic — always centralize in `MockerConstructionHelper`.
48
69
- Adding provider‑specific logic to `MockerTestBase` classes.
49
70
- Breaking existing public API signatures.
71
+
- Leaving touched public, protected, or protected internal members undocumented because they are obsolete or compatibility-only.
72
+
- Posting unrelated status text while working; every progress update should reflect the active task.
50
73
51
74
## 📚 Reference Examples
52
75
- See `FastMoq.Tests` for usage of `MockerTestBase<T>` and `VerifyLogger`.
@@ -60,6 +83,142 @@ When generating code:
60
83
61
84
---
62
85
86
+
## 🎯 V2 Refactor Roadmap & Milestones
87
+
88
+
### ✅ **Objective**
89
+
Refactor FastMoq to support a **provider-agnostic mocking architecture**, a **fluent scenario builder**, and **structured logging**, while preserving developer experience and minimizing migration friction from v1 to v2.
90
+
91
+
### 🧭 **Summary of Changes**
92
+
- Introduce a **plugin-based provider model** to support Moq, NSubstitute, FakeItEasy, and custom mocking engines.
93
+
- Build a **strongly-typed fluent API** for expressive, chainable test scenarios.
94
+
- Add **structured logging and diagnostics** for mock setup, execution, and verification.
95
+
- Ensure **backward compatibility** by preserving public interface names or providing migration shims.
96
+
- Design for **extensibility** and **session-resilient refactoring**, so work can continue across sessions.
0 commit comments