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

Allow setting up async methods easily #64

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

Allow setting up async methods easily #64

jdom opened this issue Dec 9, 2013 · 5 comments

Comments

@jdom
Copy link
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.

@kzu
Copy link
Member

kzu commented Dec 10, 2013

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

@jdom
Copy link
Contributor Author

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.

@kzu
Copy link
Member

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//issues/64#issuecomment-30236958
.

alextercete pushed a commit to alextercete/moq4 that referenced this issue Dec 10, 2013
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 devlooped#64.
@jdom
Copy link
Contributor Author

jdom commented Dec 11, 2013

Nice!

alextercete pushed a commit to alextercete/moq4 that referenced this issue Dec 13, 2013
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 devlooped#64.
@stakx
Copy link
Contributor

stakx commented Jun 3, 2017

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

@stakx stakx closed this as completed Jun 3, 2017
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

No branches or pull requests

3 participants