chore(mocks): regenerate source generator snapshots

[thomhurst]

Summary

Regenerate the TUnit.Mocks source-generator snapshot baselines to match the current generator output after the recent mocks fixes (#5677 / #5678 / #5679 / #5680 / #5681 / #5682 / #5683 / #5684).

Changes

• 1 snapshot file updated: Class_Implementing_Static_Abstract_Interface.verified.txt
• The drift is a single-line addition of [global::System.Diagnostics.CodeAnalysis.SetsRequiredMembers] on the generated mock constructor — directly matching the intent of [Bug] TUnit.Mocks: mocking a type with required members fails with CS9035 #5678 ("fix(mocks): emit [SetsRequiredMembers] on generated mock ctor").

Verification

• Spot-checked the diff: legitimate generator output change, not a bug. Generated C# is well-formed.
• Before regen: 48 passed / 1 failed (on net10.0).
• After regen: 49 passed / 0 failed.

Test plan

• dotnet build TUnit.Mocks.SourceGenerator.Tests/TUnit.Mocks.SourceGenerator.Tests.csproj
• dotnet run --framework net10.0 --no-build in TUnit.Mocks.SourceGenerator.Tests/ — all 49 tests pass
• Only .verified.txt files touched; no .received.txt committed

[claude]

Code Review

Summary: Single-line snapshot baseline update adding [global::System.Diagnostics.CodeAnalysis.SetsRequiredMembers] to the generated mock constructor for StaticAbstractImplMockImpl.

Change Analysis

The addition is correct and appropriate. [SetsRequiredMembers] is needed on constructors that satisfy required member initialization, so consumers don't need to use object-initializer syntax to set required properties after construction. This directly matches the intent of #5678.

Scope check: The PR description notes 48/1 → 49/0 (before/after), which confirms this was the sole failing snapshot. No other baselines were missed — classes without required members correctly don't carry this attribute on their constructors.

Convention compliance:

• ✅ Only .verified.txt touched — no .received.txt committed (per project rules)
• ✅ Snapshot accepted rather than suppressed or worked around
• ✅ Commit message follows chore(mocks): convention

No issues found. This is a clean, minimal, and purposeful snapshot baseline update that properly closes the test regression introduced by the mocks fixes in #5677–#5684. Good work keeping the baselines tight and not over-regenerating unrelated snapshots.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[thomhurst]

The windows-latest modularpipeline failure on this PR is unrelated to this PR's changes (which only regenerate one .verified.txt snapshot file).

Root cause

TUnit.Assertions.Tests.ExecutionTimeTests.Completes_Within_Unhappy (net8.0) failed with a flaky timing assertion:

AssertionException: Expected to be less than 00:00:01
but received 00:00:02.3657737
  at Assert.That(duration).IsLessThan(TimeSpan.FromSeconds(1))
  at TUnit.Assertions.Tests.ExecutionTimeTests.Completes_Within_Unhappy() in ExecutionTimeTests.cs:30

The test launches an action that calls Thread.Sleep(10000), asserts a 250ms timeout fires as expected, then asserts the total stopwatch elapsed is < 1 second. On a slow/contended Windows runner, cleanup from the sleeping thread (or CI scheduling jitter) can exceed 1s. This is a pre-existing flaky test, not introduced by this PR.

Evidence it is pre-existing

The most recent main run (24864304955) also failed its modularpipeline jobs. On main, all three OS runners fail RunMockSourceGeneratorTestsModule on the Class_Implementing_Static_Abstract_Interface snapshot — which is exactly what this PR fixes. On this PR, the RunMockSourceGeneratorTestsModule step passes on every OS, and only windows-latest hit the unrelated flake.

Recommendation

This PR can be merged as-is. The Completes_Within_Unhappy test should be loosened (or re-run on failure) in a follow-up.