Allow setting up async methods easily #64

Closed
jdom opened this Issue Dec 9, 2013 · 5 comments

Comments

Projects
None yet
3 participants
Contributor

jdom commented Dec 9, 2013

It would be nice to have better usability for methods that return Task.

For example, an option for doing something like:

myMock.Setup(x => x.ReadAsync()).ThrowsAsync(new Exception());

which should return a faulted task with that exception.

Also, for methods that return Task that are not explicitly set up, it would be good that instead of defaulting to return a null Task, that they return a completed Task (or completed Task) instead.

Didn't consider the best way to address this yet, but currently it can be a little cumbersome especially when mocking code where >70% of its methods are async.

Owner

kzu commented Dec 10, 2013

What's missing from the merged PR #60 to satisfy this?

Contributor

jdom commented Dec 10, 2013

I didn't know about those extensions. Those definitely help, although I guess they might be in the wrong namespace, as being extension methods they are not that easily discoverable because we typically do not add a using for Moq.Language.Flow (or is this where all extensions are defined?)

Do you think we should move them to just Moq namespace or will they pollute the main namespace unnecessarily?

Also, ideally, all methods that return Task or Task< T> should by default return a completed Task with the default value, instead of a null Task. With this last thing I believe Moq could be of great value also with async code.

Owner

kzu commented Dec 10, 2013

Good point. Yes, the extension methods should be under Moq namespace.

+1 on the default value for Task. That should be an easy fix :)

/kzu

Daniel Cazzulino

On Tue, Dec 10, 2013 at 12:32 PM, jdom notifications@github.com wrote:

I didn't know about those extensions. Those definitely help, although I
guess they might be in the wrong namespace, as being extension methods they
are not that easily discoverable because we typically do not add a using
for Moq.Language.Flow (or is this where all extensions are defined?)

Do you think we should move them to just Moq namespace or will they
pollute the main namespace unnecessarily?

Also, ideally, all methods that return Task or Task should by default
return a completed Task with the default value, instead of a null Task.
With this last thing I believe Moq could be of great value also with async
code.


Reply to this email directly or view it on GitHubhttps://github.com/Moq/moq4/issues/64#issuecomment-30236958
.

alextercete pushed a commit to alextercete/moq4 that referenced this issue Dec 10, 2013

Avoid NullReferenceException with async methods
When using async methods and loose Mock Behavior, calls to Task methods
give NullReferenceException, since default(Task) is null. Calls to
Task.Wait() and Task<T>.Result should follow the loose behavior: do
nothing and return the default value for T, respectively.

Related to #64.
Contributor

jdom commented Dec 11, 2013

Nice!

alextercete pushed a commit to alextercete/moq4 that referenced this issue Dec 13, 2013

Avoid NullReferenceException with async methods
When using async methods and loose Mock Behavior, calls to Task methods
give NullReferenceException, since default(Task) is null. Calls to
Task.Wait() and Task<T>.Result should follow the loose behavior: do
nothing and return the default value for T, respectively.

Related to #64.
Member

stakx commented Jun 3, 2017

Closing this issue since all that it asked for has been implemented since.

@stakx stakx closed this Jun 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment