-
-
Notifications
You must be signed in to change notification settings - Fork 798
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
Comments
What's missing from the merged PR #60 to satisfy this? |
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. |
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:
|
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.
Nice! |
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.
Closing this issue since all that it asked for has been implemented since. |
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.
The text was updated successfully, but these errors were encountered: