I ran into a strange behavior of NUnit tests with async delegates.
MyAsyncTest, where I declare the delegate beforehand, fails with System.ArgumentException : Async void methods are not supported. Please use 'async Task' instead.
MyAsyncTest2, where I paste delegate right in, passes.
[Test] //fails
public void MyAsyncTest()
{
TestDelegate testDelegate = async () => await MyTestMethod();
Assert.That(testDelegate, Throws.Exception);
}
[Test] //passes
public void MyAsyncTest2()
{
Assert.That(async () => await MyTestMethod(), Throws.Exception);
}
private async Task MyTestMethod()
{
await Task.Run(() => throw new Exception());
}
Can someone explain?
The problem here is in async void callbacks.
Since 'MyAsyncTest1' uses TestDelegate and it returns void(it becomes async void), it can't handle Exception properly.
If you pay attention in 'MyAsyncTest2' test the type of argument is ActualValueDelegate with Task return type (meaning the Exception will be handled correctly).
To fix the issue you have to explicitly specify the return type to be Task. See provided example.
public class Tests
{
[Test]
public void MyAsyncTest()
{
Func<Task> testDelegate = async () => await MyTestMethod();
Assert.That(testDelegate, Throws.Exception);
}
private async Task MyTestMethod()
{
await Task.Run(() => throw new Exception());
}
}
Related
In program, we have:
var task1 = some task;
task1.start()
If mock the task result in unit test, the result is returned by mock mechanism immediately before calling the start(), and raise "Start may not be called on a task that has completed" exception.
How to address that issue and compose a valid unit test?
Paste a simplified sample code here for clarity, which produces the above exception:
namespace TestTaskStart
{
public class TestMethods : ITestMethods
{
public async Task<int> AlwaysReturnOne(int number)
{
return await Task.FromResult(1);
}
}
}
namespace TestTaskStart {
public class TestInvoker
{
private ITestMethods testMethods;
public TestInvoker(ITestMethods testMethods)
{
this.testMethods = testMethods;
}
public async Task<int> GetANumberWrapperTask(int number)
{
// just an exmple of one tasks to be called
var task = this.testMethods.AlwaysReturnOne(number);
task.Start();
Task.WaitAll(task);
return task.Result;
}
}
}
namespace TestTaskStart {
[TestClass]
public class UnitTests
{
ITestMethods numberGetter;
TestInvoker testInvoker;
[TestInitialize]
public void Setup()
{
this.numberGetter = Substitute.For<ITestMethods>();
this.testInvoker = new TestInvoker(this.numberGetter);
}
[TestMethod]
public void TestGetANumberWrapper()
{
this.MockAlwaysReturnOneResult();
var result = testInvoker.GetANumberWrapperTask(5).Result;
}
private void MockAlwaysReturnOneResult()
{
this.numberGetter.AlwaysReturnOne(Arg.Any<int>()).Returns(1);
}
}
}
The Task.Start method can only be called on "cold" tasks, in other words on tasks that have not been started yet. Such tasks can only be created with the Task constructor. Tasks created by invoking asynchronous methods implemented with the async keyword are "hot", in other words they are already started upon creation. From the docs:
Exceptions
InvalidOperationException
The Task is not in a valid state to be started. It may have already been started, executed, or canceled, or it may have been created in a manner that doesn't support direct scheduling.
This is also a good reading: A Tour of Task, Part 10: Promise Tasks
I have two methods:
public class MyClass
{
public virtual async Task MethodOne(MyModel myModel)
{
await Task.Delay(1);
throw new Exception("Test");
}
public async Task MethodTwo()
{
MyModel myModel = new MyModel();
await MethodOne(myModel);
}
}
It doesn't matter what MyModel is, but it does matter that it's a parameter.
And the test:
[Fact]
public async Task Test6()
{
// Arrange
MyClass myClass = Substitute.ForPartsOf<MyClass>();
myClass.When(async a => await a.MethodOne(Arg.Any<MyModel>())).DoNotCallBase();
// Act
await myClass.MethodTwo();
// Assert
}
The test gives a NullReferenceException when the line:
myClass.When(async a => await a.MethodOne(Arg.Any<MyModel>())).DoNotCallBase();
My guess is that it is, in some way, trying to resolve MyModel; however, the same test works, when performed on a synchronous method, or one without a complex parameter.
Can anyone tell me why this error occurs in this way?
Do not await the setup
overridden method needs to return a Task to allow async to flow to completion when invoked in test.
That means the setup needs to be rewritten
[Fact]
public async Task Test6() {
// Arrange
var myClass = Substitute.ForPartsOf<MyClass>();
myClass.MethodOne(Arg.Any<MyModel>()).Returns(Task.FromResult((object)null));
// Act
await myClass.MethodTwo();
// Assert
//...
}
I'm a bit stuck with this code (this is a sample):
public async Task Fail()
{
await Task.Run(() => { throw new Exception(); });
}
[Test]
public async Task TestFail()
{
Action a = async () => { await Fail(); };
a.ShouldThrow<Exception>();
}
The code doesn't catch the exception, and fails with
Expected a System.Exception to be thrown, but no exception was
thrown.
I'm sure I'm missing something, but docs seem to suggest this is the way to go. Some help would be appreciated.
You should use Func<Task> instead of Action:
[Test]
public void TestFail()
{
Func<Task> f = async () => { await Fail(); };
f.ShouldThrow<Exception>();
}
That will call the following extension which is used to verify asynchronous methods
public static ExceptionAssertions<TException> ShouldThrow<TException>(
this Func<Task> asyncAction, string because = "", params object[] becauseArgs)
where TException : Exception
Internally this method will run task returned by Func and wait for it. Something like
try
{
Task.Run(asyncAction).Wait();
}
catch (Exception exception)
{
// get actual exception if it wrapped in AggregateException
}
Note that test itself is synchronous.
With Fluent Assertions v5+ the code will be like :
ISubject sut = BuildSut();
//Act and Assert
Func<Task> sutMethod = async () => { await sut.SutMethod("whatEverArgument"); };
await sutMethod.Should().ThrowAsync<Exception>();
This should work.
Other variation of usage ThrowAsync method:
await Should.ThrowAsync<Exception>(async () => await Fail());
With Fluent Assertions v5.7 they introduced the Awaiting overload so now you can do as following:
public async void TestFail()
{
await this.Awaiting(_ => Fail()).Should().ThrowAsync<Exception>();
}
With Fluent Assertions v6.9 you can use short form:
var act = () => Fail();
act.Should().ThrowAsync<Exception>();
I have a method with some code that does an await operation:
public async Task DoSomething()
{
var x = await ...;
}
I need that code to run on the Dispatcher thread. Now, Dispatcher.BeginInvoke() is awaitable, but I can't mark the lambda as async in order to run the await from inside it, like this:
public async Task DoSomething()
{
App.Current.Dispatcher.BeginInvoke(async () =>
{
var x = await ...;
}
);
}
On the inner async, I get the error:
Cannot convert lambda expression to type 'System.Delegate' because it is not a delegate type.
How can I work with async from within Dispatcher.BeginInvoke()?
The other answer may have introduced an obscure bug. This code:
public async Task DoSomething()
{
App.Current.Dispatcher.Invoke(async () =>
{
var x = await ...;
});
}
uses the Dispatcher.Invoke(Action callback) override form of Dispatcher.Invoke, which accepts an async void lambda in this particular case. This may lead to quite unexpected behavior, as it usually happens with async void methods.
You are probably looking for something like this:
public async Task<int> DoSomethingWithUIAsync()
{
await Task.Delay(100);
this.Title = "Hello!";
return 42;
}
public async Task DoSomething()
{
var x = await Application.Current.Dispatcher.Invoke<Task<int>>(
DoSomethingWithUIAsync);
Debug.Print(x.ToString()); // prints 42
}
In this case, Dispatch.Invoke<Task<int>> accepts a Func<Task<int>> argument and returns the corresponding Task<int> which is awaitable. If you don't need to return anything from DoSomethingWithUIAsync, simply use Task instead of Task<int>.
Alternatively, use one of Dispatcher.InvokeAsync methods.
I think you can use below code and then depends of place use it with async and await or without to fire and forget:
public static Task FromUiThreadAsync(Action action)
{
TaskCompletionSource<bool> tcs = new TaskCompletionSource<bool>();
Dispatcher disp = GetUiDispatcher();
disp.Invoke(DispatcherPriority.Background, new Action(() =>
{
try
{
action();
tcs.SetResult(true);
}
catch (Exception ex)
{
tcs.SetException(ex);
}
}));
return tcs.Task;
}
Use Dispatcher.Invoke()
public async Task DoSomething()
{
App.Current.Dispatcher.Invoke(async () =>
{
var x = await ...;
});
}
(Edit: This answer is wrong, but I'll fix it soon)
Declare this
public async Task DoSomethingInUIThreadAsync(Func<Task> p)
{
await Application.Current.Dispatcher.Invoke(p);
}
Use like this
string someVar = "XXX";
DoSomethingInUIThreadAsync(()=>{
await Task.Run(()=> {
Thread.Sleep(10000);
Button1.Text = someVar;
});
});
DoSomethingInUIThreadAsync receives a delegate that returns a Task, Application.Current.Dispatcher.Invoke accepts a Func callback that can be awaited.
I want to unit test a method that I have that performs and async operation:
Task.Factory.StartNew(() =>
{
// method to test and return value
var result = LongRunningOperation();
});
I stub the necessary methods etc in my unit test (written in c#) but the problem is that the async operation is not finished before I assert the test.
How can I get around this? Should I create a mock of the TaskFactory or any other tips to unit testing an async operation?
You'd have to have some way of faking out the task creation.
If you moved the Task.Factory.StartNew call to some dependency (ILongRunningOperationStarter) then you could create an alternative implementation which used TaskCompletionSource to create tasks which complete exactly where you want them to.
It can get a bit hairy, but it can be done. I blogged about this a while ago - unit testing a method which received tasks to start with, which of course made things easier. It's in the context of async/await in C# 5, but the same principles apply.
If you don't want to fake out the whole of the task creation, you could replace the task factory, and control the timing that way - but I suspect that would be even hairier, to be honest.
I would propose to stub a TaskScheduler in your method with a special implementation for unit tests. You need to prepare your code to use an injected TaskScheduler:
private TaskScheduler taskScheduler;
public void OperationAsync()
{
Task.Factory.StartNew(
LongRunningOperation,
new CancellationToken(),
TaskCreationOptions.None,
taskScheduler);
}
In your unit test you can use the DeterministicTaskScheduler described in this blog post to run the new task on the current thread. Your 'async' operation will be finished before you hit your first assert statement:
[Test]
public void ShouldExecuteLongRunningOperation()
{
// Arrange: Inject task scheduler into class under test.
DeterministicTaskScheduler taskScheduler = new DeterministicTaskScheduler();
MyClass mc = new MyClass(taskScheduler);
// Act: Let async operation create new task
mc.OperationAsync();
// Act: Execute task on the current thread.
taskScheduler.RunTasksUntilIdle();
// Assert
...
}
Try something like this...
object result = null;
Task t = Task.Factory.StartNew(() => result = LongRunningThing());
Task.Factory.ContinueWhenAll(new Task[] { t }, () =>
{
Debug.Assert(result != null);
});
Set UI and background task schedulars and replace them in unit test with this one.
Below code was copied from internet, sorry for missing reference to author:
public class CurrentThreadTaskScheduler : TaskScheduler
{
protected override void QueueTask(Task task)
{
TryExecuteTask(task);
}
protected override bool TryExecuteTaskInline(
Task task,
bool taskWasPreviouslyQueued)
{
return TryExecuteTask(task);
}
protected override IEnumerable<Task> GetScheduledTasks()
{
return Enumerable.Empty<Task>();
}
public override int MaximumConcurrencyLevel => 1;
}
So to test code:
public TaskScheduler TaskScheduler
{
get { return taskScheduler ?? (taskScheduler = TaskScheduler.Current); }
set { taskScheduler = value; }
}
public TaskScheduler TaskSchedulerUI
{
get { return taskSchedulerUI ?? (taskSchedulerUI = TaskScheduler.FromCurrentSynchronizationContext()); }
set { taskSchedulerUI = value; }
}
public Task Update()
{
IsBusy = true;
return Task.Factory.StartNew( () =>
{
LongRunningTask( );
}, CancellationToken.None, TaskCreationOptions.None, TaskScheduler )
.ContinueWith( t => IsBusy = false, TaskSchedulerUI );
}
You will write following unit test:
[Test]
public void WhenUpdateThenAttributeManagerUpdateShouldBeCalled()
{
taskScheduler = new CurrentThreadTaskScheduler();
viewModel.TaskScheduler = taskScheduler;
viewModel.TaskSchedulerUI = taskScheduler;
viewModel.Update();
dataManagerMock.Verify( s => s.UpdateData( It.IsAny<DataItem>>() ) );
}