Setup sequence doesn't support ReturnsAsync with Func<>

[kswider]

In SetupSequence there is an overload for Returns can that take Func<> as an argument, but there isn't such overload for ReturnsAsync.

I think that adding this overload to ReturnsAsync would be a nice enhancement.

[stakx]

Would you like to provide the implementation for it?

[kswider]

Yea, I think I can make it :)

[VladFasie]

could you please detail the requirements ?

[stakx]

@VladFasie:

The existing non-async method sequenceSetup.Returns(Func<T> valueFactory) returns a value of type T that is equal to whatever valueFactory() returns. Evaluating valueFactory happens once per invocation of the sequence setup.

I'd expect the planned sequenceSetup.ReturnsAsync(Func<T> valueFactory) to do the same, i.e. it should return a completed [Value]Task<T> whose .Result property equals the value produced by valueFactory(). Neither the result of that call nor the returned task should be cached, i.e. every invocation of the sequence setup produces a new task.

[VladFasie]

I can't make my branch public.

git push --set-upstream origin "#795"
remote: Permission to moq/moq4.git denied to VladFasie.
fatal: unable to access 'https://github.com/moq/moq4.git/': The requested URL returned error: 403

[stakx]

@VladFasie - First, please coordinate your efforts with @kswider, as he stated above that he might be working on this as well. It would be a shame if both of you work on this separately, as I will only be able to merge the changes from one of you.

If @kswider is fine with you going ahead here, then please send a pull request (PR) via GitHub. That is:

1. Fork this repository to your own GitHub account.
2. Clone your own fork repository.
3. Create a topic branch off master.
4. Add commits to that topic branch.
5. Push your branch back to your repo.
6. Submit a PR from this branch in your repository to master in this repository.

Since you've already started, you can skip 2, 3, and 4. Instead, add a remote in your local repo that points to your fork repo on GitHub.

Please make sure that you've read our contributing guide. Thanks!

P.S. not sure if GitHub handles a branch name #795 well, it might be prudent to choose a safer name like issue-795 or even something more telling, like sequencesetup-returnsasync. But that's just a suggestion, not a requirement.

[kswider]

If @VladFasie has already finished fixing that issue I'm ok with that. I planned to do it today :)

[cassdeckard]

I ran into this just yesterday and would love to see it added. In addition, there doesn't seem to be any way of accessing the arguments within the version of Returns() that takes a Func<>. Was that intentional or another oversight that could potentially be added along with this?

[stakx]

Was that intentional or another oversight that could potentially be added along with this?

Moq's API today is mostly driven by the community's needs, so it is not so much an oversight, but more that noone asked for nor implemented this.

Making these additions would certainly be possible.

(I personally think the whole SetupSequence API shouldn't be expanded much further, initially it was probably meant as a simple helper that spared you the work of setting up a callback with a state machine inside (though that remains of course possible for more complicated scenarios), it's something of a burden keeping it in synch with the main Setup API.)

[VladFasie]

I hope I will manage to come with a push in weekend

[stakx]

@kswider: @VladFasie closed his PR a moment ago. If you'd still like to proceed with this issue and submit your own, please feel free to go ahead.

[BenCoden]

Is there a workaround?
And @kswider are you making a PR?