Always emit TUnit.Mocks.Generated namespace from source generator

[Copilot]

TUnit.Mocks.targets unconditionally adds global using TUnit.Mocks.Generated; to consuming projects, but the namespace only exists when the source generator has produced mock code. Installing TUnit.Mocks without any Mock.Of<T>() usage causes CS0234 at build time.

Changes

• MockGenerator.cs: Added RegisterPostInitializationOutput to always emit a minimal file declaring the TUnit.Mocks.Generated namespace, regardless of whether any mocks are discovered:

context.RegisterPostInitializationOutput(ctx =>
{
    ctx.AddSource("TUnit.Mocks.Generated.Namespace.g.cs", """
        // <auto-generated/>
        #nullable enable

        namespace TUnit.Mocks.Generated;
        """);
});

• Snapshots: Updated all 16 .verified.txt files to include the new namespace file in expected output

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[claude]

Review: Always emit TUnit.Mocks.Generated namespace from source generator

Summary

This PR fixes a real bug: TUnit.Mocks.targets unconditionally injects global using TUnit.Mocks.Generated;, but the namespace only exists when the source generator has emitted at least one mock. Installing the package without any Mock.Of<T>() usage causes a CS0234 build error. The fix is correct and the approach is sound.

---

What Works Well

• Using RegisterPostInitializationOutput is exactly the right Roslyn API for this purpose. It runs unconditionally before any syntax-driven pipeline steps and its output is guaranteed to always be emitted, which is precisely the invariant needed here.
• The generated file is minimal — just the namespace declaration — so there's no unnecessary code in projects that don't use mocks.
• Snapshot tests were updated to reflect the new output, following the project's snapshot-testing conventions.

---

Concerns and Suggestions

1. Missing snapshot test for the zero-mock scenario (the actual bug case)

The existing snapshot tests all exercise projects with at least one Mock.Of<T>() call. The root cause of the bug is what happens with no mock usage at all — yet there's no test for that path. A test like No_Mock_Usage_Still_Emits_Namespace that compiles a source file referencing TUnit.Mocks but containing no Mock.Of<T>() call would directly capture the regression. Without it, a future change that inadvertently removes the RegisterPostInitializationOutput call would not be caught by the snapshot suite.

2. Order of the generated file in snapshots is surprising

Because RegisterPostInitializationOutput runs before the syntax-driven pipeline, and SnapshotTestBase sorts generated files by file path using StringComparer.Ordinal, the namespace stub (TUnit.Mocks.Generated.Namespace.g.cs) will sort after all the type-specific files in the current snapshots (e.g. it appears last in every .verified.txt). This is not a bug, but it is counterintuitive — readers scanning a snapshot may be confused by a bare namespace declaration appended at the end after a full mock implementation. A comment in SnapshotTestBase.RunGeneratorAndFormat or a note in the file itself would clarify why it always appears.

3. The namespace stub could declare the file-scoped namespace more explicitly

The current generated content is:

// <auto-generated/>
#nullable enable

namespace TUnit.Mocks.Generated;

This is syntactically valid and will compile, but it declares an empty file-scoped namespace with no members. There is a tiny risk that some downstream tool (e.g. a documentation generator or an overzealous analyzer) emits a warning about an empty namespace. A common defensive pattern is to add a dummy internal marker type:

namespace TUnit.Mocks.Generated
{
    // Marker type emitted unconditionally to ensure the namespace always exists.
    internal static class __Namespace__ { }
}

This is optional — the empty file-scoped namespace compiles cleanly — but it makes the intent unambiguous and sidesteps any analyzer noise about empty namespaces.

4. Consider guarding the global using with a build property instead

An alternative (arguably more robust) design would be to make the .targets injection conditional on the source generator having something to emit, or to use the existing TUnitMockImplicitUsings escape hatch to let users opt out. However, emitting a guaranteed namespace stub from the generator is simpler and more transparent than a conditional MSBuild property, so the chosen approach is reasonable. This is purely a note, not a blocker.

---

Bottom Line

The fix is correct and the API used is appropriate. The main actionable gap is a dedicated snapshot test for the zero-mock scenario that reproduces the exact bug described in the PR. Adding that test would give confidence the fix is verified and prevent future regressions.

[claude]

Follow-up Review

Picking up from the previous review — a new commit was added after that review: d6d2c1ef fix: pass parseOptions to CSharpGeneratorDriver to fix language version mismatch.

---

New Commit Analysis

TUnit.Mocks.SourceGenerator.Tests/SnapshotTestBase.cs

-GeneratorDriver driver = CSharpGeneratorDriver.Create(generator);
+GeneratorDriver driver = CSharpGeneratorDriver.Create([generator.AsSourceGenerator()], parseOptions: parseOptions);

This is a meaningful fix, not cosmetic. Two things were wrong before:

1. Missing parseOptions: Without forwarding the parse options, the CSharpGeneratorDriver was running against a mismatched language version. This matters because the post-initialization output uses file-scoped namespace syntax (namespace TUnit.Mocks.Generated;), which requires C# 10+. If tests were compiled against an older parse option, the generated stub would fail to round-trip through the compilation correctly. Passing the options through ensures the test harness and the compilation are aligned.

2. generator.AsSourceGenerator(): CSharpGeneratorDriver.Create accepts ISourceGenerator[], not IIncrementalGenerator[]. Passing the IIncrementalGenerator directly worked via an implicit adaptation, but calling .AsSourceGenerator() is the explicit, documented API to wrap an incremental generator. Using it is clearer and avoids any ambiguity about which overload is resolved.

Both of these are good improvements to the test infrastructure.

---

Outstanding Concern from Previous Review

The main gap identified previously is still present: there is no snapshot test covering the zero-mock scenario (i.e., a project that references TUnit.Mocks but contains no Mock.Of<T>() calls). This is precisely the regression case described in the PR description. All 16 existing snapshot tests exercise the generator with at least one mock interface, so a future removal of RegisterPostInitializationOutput would go undetected by the test suite.

A test like this would close the gap:

[Test]
public Task No_Mock_Usage_Emits_Namespace_File()
{
    // Source with no Mock.Of<T>() calls
    var source = "public class Foo { }";
    var results = RunGenerator(source);
    // Should still contain TUnit.Mocks.Generated.Namespace.g.cs
    return Verify(results);
}

---

Bottom Line

The new commit is a solid improvement to the test harness and correctly addresses the language version alignment issue. The core fix (RegisterPostInitializationOutput) remains correct. The one actionable gap is still the missing zero-mock snapshot test to explicitly verify the bug scenario reported in the PR description.

[claude]

Code Review

Fix is correct and well-targeted. The root cause (global using targeting a namespace that only exists after code generation) and the solution (always-emit via RegisterPostInitializationOutput) are both sound.

What's good

• Using RegisterPostInitializationOutput is the idiomatic Roslyn incremental generator way to emit files unconditionally. It's efficient (runs once at startup, not on every re-generation), correct, and clean.
• The SnapshotTestBase.cs change is an important fix alongside the main one: passing parseOptions to CSharpGeneratorDriver.Create ensures the generator sees the correct language version (notably LanguageVersion.Preview) which the old call silently dropped.
• All 16 snapshot files are updated consistently.

Issue: Missing regression test for the actual bug scenario

The change that motivated this fix — installing TUnit.Mocks without any Mock.Of<T>() usage causing CS0234 — has no dedicated test. Every existing snapshot test exercises a project with mock usage, so they don't cover the empty case.

A test like this would directly validate the fix and prevent regression:

[Test]
public Task No_Mock_Usages_Still_Emits_Namespace_File()
{
    // Reproduces: CS0234 when TUnit.Mocks installed but no Mock.Of<T>() used
    var source = """
        // No Mock.Of<T>() calls — namespace file must still be emitted
        public class SomeClass { }
        """;

    return VerifyGeneratorOutput(source);
}

This would produce a snapshot containing only the namespace file, confirming the fix works for the exact scenario described in the PR description. Without it, a future refactor could accidentally revert to conditional emission and the test suite would still pass.

Minor: missing trailing newline in emitted file

The generated file ends without a newline:

namespace TUnit.Mocks.Generated;

(confirmed by \ No newline at end of file in every snapshot diff)

This is cosmetically inconsistent with typical generated file conventions and shows up in every snapshot. Adding a trailing newline to the raw string in RegisterPostInitializationOutput would clean this up:

ctx.AddSource("TUnit.Mocks.Generated.Namespace.g.cs", """
    // <auto-generated/>
    #nullable enable

    namespace TUnit.Mocks.Generated;
    """);  // <-- add a blank line before the closing triple-quote

Summary

The core fix is correct and the approach is idiomatic. The two items above are worth addressing — the missing test in particular, since this is exactly the kind of edge case (no user code triggering the generator) that's easy to overlook in future changes.