Limit Mock.Verify() recursion to framework-created inner mocks

[Copilot]

Mock.Verify() currently walks into any mock returned by a setup, so verifying one mock can fail on unmet verifiable setups configured on a different mock. This shows up when using explicit .Returns(otherMock.Object) and verifying mocks in separate phases.

• Behavioral fix: scope recursive verification

  • Updated verification traversal in Mock.Verify to recurse only through InnerMockSetup (i.e., Moq-created object-graph links), instead of recursing through all setups.
  • This preserves recursive verification for true inner-mock chains while preventing cross-mock leakage for explicitly returned mocks.

• Regression coverage: issue scenario

  • Added Issue1699 regression test in IssueReportsFixture that reproduces:
    • mockOne.Setup(...).Returns(mockTwo.Object).Verifiable();
    • mockTwo.Setup(...).Verifiable();
    • mockOne.Verify() should succeed before mockTwo interactions occur.

• Example of the affected pattern

  mockOne.Setup(x => x.GetSomething()).Returns(mockTwo.Object).Verifiable();
  mockTwo.Setup(x => x.DoSomething()).Verifiable();
  
  objectToTest.FirstMethod();
  mockOne.Verify();   // should verify only mockOne expectations
  
  objectToTest.SecondMethod();
  mockTwo.Verify();

• Fixes .Verify() on one mock complains over missing invocations on another mock #1699

[kzu]

🧪 Details on Microsoft Windows 10.0.26100

from retest v1.1.0 on .NET 10.0.12 with 💜 by @devlooped

[kzu]

@copilot test failure in CI, is it a wrong test that verified a buggy behavior?

[Copilot]

@copilot test failure in CI, is it a wrong test that verified a buggy behavior?

Good catch — it exposed a regression from my first fix, not a buggy test. StubExtensionsFixture.Property_stubbed_by_SetupAllProperties_during_DefaultValue_Mock_has_initial_value_included_in_verification should fail verification, and I restored that behavior in c48affc while still keeping the issue #1699 fix.

[kzu]

@copilot verify this fix, seems weird that we'd check for the setup not being a MethodCall?

[Copilot]

@copilot verify this fix, seems weird that we'd check for the setup not being a MethodCall?

You were right to question that check. I verified behavior and replaced it with an explicit allowlist in a6bcec8: recursion now only applies to InnerMockSetup, StubbedPropertySetup, and StubbedPropertiesSetup. That keeps #1699 fixed while preserving SetupAllProperties verification semantics.