Closed JeppeSN closed 1 month ago
@JeppeSN I think this is already supported by the Microsoft rolsyn analyzers (ex: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/cs4014?f1url=%3FappId%3Droslyn%26k%3Dk(CS4014)
for example:
you can enforce this using .editorconfig
@JeppeSN I think this is already supported by the Microsoft rolsyn analyzers (ex: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/cs4014?f1url=%3FappId%3Droslyn%26k%3Dk(CS4014)
for example:
you can enforce this using
.editorconfig
@Meir017, Your example is different from mine in that your TestMethod AssertThrowExceptionAsync
is already declared async
. In that situation, it is likely the test author will see the problem. However, in my experience, some people write a synchronous TestMethod public void BlahBlah()
, and in that case they can fool themselves with no compiler warning.
you can use https://github.com/Microsoft/vs-threading/blob/main/doc/analyzers/VSTHRD110.md
Basically add https://www.nuget.org/packages/Microsoft.VisualStudio.Threading and then you will get diagnostics
Description
I find that the analyzers should warn people if they say
.Should().ThrowAsync<>()
and similar, without actually awaiting the task produced by Fluent Assertions.Complete minimal example reproducing the issue
Consider this code to be tested:
Then consider this attempt at proving that the methods in
C
will throw:The problem here is that the test is green. The author of it might think he has written a valid test proving the methods throw.
Actual behavior:
I see no help from FluentAssertions.Analyzers.
Expected behavior:
It would be nice to have some kind of diagnosis from the analyzer saying this is not a good use of Fluent Assertions. It might suggest that the author turns the test method
X
into anasync
method, and then usesawait
in front of the two expression statements.Of course, the author could do other things, including appending
Wait()
to the end of the expressions.Versions
Additional Information
I have seen more than one developer falling in this trap.
In the examples, I used
ThrowExactlyAsync<>()
. But I think it could be many other methods:.ThrowAsync<>
.NotThrowAsync
.NotThrowAsync<>
.ThrowExactlyAsync<>
.ThrowWithinAsync<>
.NotThrowAfterAsync
.CompleteWithinAsync
.NotCompleteWithinAsync
and possibly others.
A couple of years ago, an experienced Stack Overflow user posted the following question: https://stackoverflow.com/questions/70006484/