-
Notifications
You must be signed in to change notification settings - Fork 249
Uncovered branches in C# async methods #352
Comments
Hmm it may be possible - we've recently started ignoring branches in other auto-generated code (e.g. yield) so if we can find a nice way to identify them before we instrument them we can have a go at ignoring them. Are you able to create a repeat sceanrio that I can add to my test suite that is not so coupled to your code just so know I am looking at the right issue, it'll just save time when someone gets round to looking at the issue. |
@sawilde I haven't run this code through OpenCover, but I expect it to reproduce the described behavior. Together, public void TestCompletedTask()
{
ExampleMethodAsync(Task.FromResult(0)).GetAwaiter().GetResult();
}
public void TestIncompleteTask()
{
ExampleMethodAsync(Task.Delay(TimeSpan.FromMilliseconds(10))).GetAwaiter().GetResult();
}
public async Task ExampleMethodAsync(Task antecedent)
{
await antecedent;
} |
Thanks that makes things much clearer |
Since after await keyword must be only a method with limited return values, no user defined branches exist in that sequence point. This can be recognized by "await " string and branches removed. |
No need to fix, compiler generated branches for await are already excluded by recent changes. @sharwell |
@sharwell |
We're having a bit of trouble with the handling of
async
methods in the StyleCopAnalyzers project. These methods are compiled to a state machine, andawait
expressions within the method result in a branch which is difficult to impossible to cover both cases. Specifically, if the evaluated awaitable is already done, execution of the state machine continues on the current thread. Otherwise, it registers a continuation and returns.This behavior can be observed in the results for our SA1000UnitTests.cs file.
It would be nice if an option were available to treat coverage of either branch direction as fully covered in this specific case. Based on the results of DotNetAnalyzers/StyleCopAnalyzers#1546 (our failed workaround attempt), I estimate that this issue is responsible for nearly 10% gap in our overall code coverage reporting.
The text was updated successfully, but these errors were encountered: