Mock.HasSetup(mock, x => x.Foo)

[JohanLarsson]

I implemented this with reflection from the outside. What do you think about a PR adding this?

The use case was when using a container in tests and setting up default values. I only wanted to set up the default value if there was no prior setup. It was all pretty nasty :)

[stakx]

Was there a specific reason why you couldn't just define the default values first, then perform the setups (to override the default values)?

[stakx]

@JohanLarsson - you mentioned in a different place that this was more of a question. Is there anything to be done here, still, or should we close this?

Let me quickly summarise a thought that I've had about this request. Different people might want different things from such an overload. People might expect that this new method answers the following questions for them:

• Is there a specific setup with the given setup expression? For example, mock.HasSetup(m => m.DoSomething(It.IsAny<TArg1>(), ...). This could easily get complex since you might also want to ask whether there is such a setup that returns a particular value. Or, people might expect that less specific setup expressions (those including matchers) "include" more specific ones (those including constants). IMHO, such a method should be avoided, it's a Pandora's box waiting to be opened.

• The simpler case: Is there any setup for a member X? For example, mock.HasSetupFor(m => m.DoSomething). This is probably what you suggested, and much more doable than the above. But even this comes at a small but existent maintenance cost, as you'd need to add many method overloads (different delegate types for different method signatures). Lots of LoC (possibly mitigated via a T4 template) for a seemingly simple feature.

I feel that we should add this feature lightly. Unless of course there's actually a frequent use case that cannot be easily solved otherwise—thus my original question in the message above this one.

[JohanLarsson]

I'll close it, hacked it with reflection.