-
-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interface Default methods are ignored #972
Comments
Before Moq can support default interface methods, DynamicProxy must add support for them; see castleproject/Core#447. |
@hahn-kev: OK, I think this can be made to work. You'll have to configure var mock = new Mock<ITest>(MockBehavior.Loose);
mock.Setup(t => t.CallMe()).Returns("hello");
+mock.Setup(t => t.CallMeDefault()).CallBase();
Assert.NotNull(mock.Object.CallMeDefault()); or at the mock level (whatever is a better fit for your tests): -var mock = new Mock<ITest>(MockBehavior.Loose);
+var mock = new Mock<ITest>(MockBehavior.Loose) { CallBase = true };
mock.Setup(t => t.CallMe()).Returns("hello");
Assert.NotNull(mock.Object.CallMeDefault()); In terms of default interface implementations, |
Bumps [Moq](https://github.com/moq/moq4) from 4.16.0 to 4.16.1. #Changelog *Sourced from [Moq's changelog](https://github.com/moq/moq4/blob/main/CHANGELOG.md).* > ## 4.16.1 (2021-02-23) > > #### Added > > * `CallBase` can now be used with interface methods that have a default interface implementation. It will call [the most specific override](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods#the-most-specific-override-rule). (@stakx, [#1130](devlooped/moq#1130)) > > #### Changed > > * Improved error message formatting of `It.Is` lambda expressions that capture local variables. (@bfriesen, [#1140](devlooped/moq#1140)) > > #### Fixed > > * `AmbiguousMatchException` raised when interface has property indexer besides property in VB. (@mujdatdinc, [#1129](devlooped/moq#1129)) > * Interface default methods are ignored (@hahn-kev, [#972](devlooped/moq#972)) > * Callback validation too strict when setting up a task's `.Result` property (@stakx, [#1132](devlooped/moq#1132)) > * `setup.Returns(InvocationFunc)` wraps thrown exceptions in `TargetInvocationException` (@stakx, [#1141](devlooped/moq#1141)) #Commits - [`fc484fb`](devlooped/moq@fc484fb) Update version to 4.16.1 - [`0ddfdb8`](devlooped/moq@0ddfdb8) `Returns(InvocationFunc)` shouldn't throw `TargetInvocationException` - [`f36d3e8`](devlooped/moq@f36d3e8) Merge pull request [#1140](devlooped/moq#1140) from bfriesen/lambda_closure_support - [`e96804f`](devlooped/moq@e96804f) Update the changelog - [`5ae449c`](devlooped/moq@5ae449c) Exclude name of the closure class - [`8a2d2ed`](devlooped/moq@8a2d2ed) Add test for closure access - [`cf5af87`](devlooped/moq@cf5af87) Format lambda expression variables - [`5b10a8c`](devlooped/moq@5b10a8c) Add test for lamba matcher variables - [`653db31`](devlooped/moq@653db31) Some minor renames for consistency - [`fc73131`](devlooped/moq@fc73131) Add missing copyright notices - Additional commits viewable in [compare view](devlooped/moq@v4.16.0...v4.16.1)
I'm not sure if this would be considered a bug, but I'd think it would work the same as mocking an abstract class.
Example
My interface has the method
CallMeDefault
which has an implementation, however when I mock that interface it gets overridden and calling that method returns null instead of whatCallMe
returns as I'd expect. I think ideally this would follow the CallBase setting, however it doesn't seem like it does.The text was updated successfully, but these errors were encountered: