Daniel Cazzulino

It seems once [Castle.Core](https://github.com/castleproject/Core/issues/447#issuecomment-2323146669) ships an update with that support, things should Just Work (or very close to that). Feel free to [back this issue](https://www.devlooped.com/SponsorLink/github/issues/?s=devlooped) if it's important for your...

Make your action parameter an `Expression` instead? That's the type `Mock.Verify` receives and is that makes it possible to inspect which mock member invocation to verify.

This is tricky indeed. I don't think I did a very good job of making things easily comprehensible from the beginning. Too much "magic" 😞 . I wonder if the...

TBH, I don't recall precisely what the original intended behavior. My intuition is that in general, recursive setups are "owned" by the mock you perform them on, where as "regular"...

Yeah, I see your point. Too many heuristics makes things harder to understand. I still haven't introduced the concept of the mock repository in v5, I was pondering whether it...

Ok, I refreshed my memory on this thread, and I think I agree with the proposed design of having mocks own setups and not entire mocks. I don't think the...

I wouldn't deprecate `VerifyNoOtherCalls`, no, it's already part of the shipped public API :). Perhaps for vNext 😉 .

Good point. What should be the expected behavior? /kzu from mobile On Dec 18, 2013 7:33 PM, "Henrique Esteves" [email protected] wrote: > When using a "MockSequence" the behavior of the...

But isn't that what verifying the sequence achieves? /kzu from mobile On Dec 19, 2013 10:20 AM, "Henrique Esteves" [email protected] wrote: > In my opinion, regardless if you are using...

there's a key issue here that I think is missing: a sequence can be used across several mocks. So any single mock in that sequence will not be able to...