Skip to content
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

Make return values of loose mock setups having no .Returns nor .CallBase more consistent #849

Merged
merged 1 commit into from
Jun 8, 2019

Conversation

stakx
Copy link
Contributor

@stakx stakx commented Jun 8, 2019

See details in commit message.

This also resolves #702.

@stakx stakx added this to the 4.12.0 milestone Jun 8, 2019
This fixes a long-standing inconsistency in how Moq produces default
return values. Given a loose mock for a type which has some member
`TResult M()`:

 * If there's no setup for `M`, the return value is determined by
   `mock.CallBase` or, if it is not set, by `mock.DefaultValue-
    [Provider]`.

 * If there is a setup for `M`, which has either a `.Returns(...)` or
   a `.CallBase()` clause, then the return value will be determined by
   that.

 * If there is a setup for `M`, but the setup has neither a
   `.Returns(...)` nor a `.CallBase()` clause, then `default(T)` will
   be returned.

The last one doesn't really fit in with the rest of how Moq handles
default values. While it may be a user mistake not to explicitly
specify the return value for a setup, it cannot hurt to make things
more consistent.

Better consistency in this case means that such "incomplete" setups
(3) will produce the same return value for M as (1).
@stakx stakx merged commit 582aac9 into devlooped:master Jun 8, 2019
@stakx stakx deleted the setup-without-returns branch June 8, 2019 15:47
ocoanet pushed a commit to ocoanet/moq4 that referenced this pull request Jun 10, 2019
This fixes a long-standing inconsistency in how Moq produces default
return values. Given a loose mock for a type which has some member
`TResult M()`:

 * If there's no setup for `M`, the return value is determined by
   `mock.CallBase` or, if it is not set, by `mock.DefaultValue-
    [Provider]`.

 * If there is a setup for `M`, which has either a `.Returns(...)` or
   a `.CallBase()` clause, then the return value will be determined by
   that.

 * If there is a setup for `M`, but the setup has neither a
   `.Returns(...)` nor a `.CallBase()` clause, then `default(T)` will
   be returned.

The last one doesn't really fit in with the rest of how Moq handles
default values. While it may be a user mistake not to explicitly
specify the return value for a setup, it cannot hurt to make things
more consistent.

Better consistency in this case means that such "incomplete" setups
(3) will produce the same return value for M as (1).
ishimko pushed a commit to ishimko/moq4 that referenced this pull request Sep 2, 2019
This fixes a long-standing inconsistency in how Moq produces default
return values. Given a loose mock for a type which has some member
`TResult M()`:

 * If there's no setup for `M`, the return value is determined by
   `mock.CallBase` or, if it is not set, by `mock.DefaultValue-
    [Provider]`.

 * If there is a setup for `M`, which has either a `.Returns(...)` or
   a `.CallBase()` clause, then the return value will be determined by
   that.

 * If there is a setup for `M`, but the setup has neither a
   `.Returns(...)` nor a `.CallBase()` clause, then `default(T)` will
   be returned.

The last one doesn't really fit in with the rest of how Moq handles
default values. While it may be a user mistake not to explicitly
specify the return value for a setup, it cannot hurt to make things
more consistent.

Better consistency in this case means that such "incomplete" setups
(3) will produce the same return value for M as (1).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adding Callback to a mock breaks async tests
1 participant