Document MSTEST0039 and MSTEST0040 #44419
+92
−4
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| title: "MSTEST0039: Use newer 'Assert.Throws' methods" | ||
| description: "Learn about code analysis rule MSTEST0039: Use 'Assert.ThrowsExactly' instead of 'Assert.ThrowsException'" | ||
| ms.date: 01/17/2025 | ||
| f1_keywords: | ||
| - MSTEST0039 | ||
| - UseNewerAssertThrowsAnalyzer | ||
| helpviewer_keywords: | ||
| - UseNewerAssertThrowsAnalyzer | ||
| - MSTEST0039 | ||
| author: Youssef1313 | ||
| ms.author: ygerges | ||
| --- | ||
| # MSTEST0039: Use newer 'Assert.Throws' methods | ||
|
|
||
| | Property | Value | | ||
| |-------------------------------------|------------------------------------------------------------------------| | ||
| | **Rule ID** | MSTEST0039 | | ||
| | **Title** | Use newer 'Assert.Throws' methods | | ||
| | **Category** | Usage | | ||
| | **Fix is breaking or non-breaking** | Non-breaking | | ||
| | **Enabled by default** | Yes | | ||
| | **Default severity** | Info | | ||
| | **Introduced in version** | 3.8.0 | | ||
| | **Is there a code fix** | Yes | | ||
|
|
||
| ## Cause | ||
|
|
||
| The use of <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException*?displayProperty=nameWithType> or <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsExceptionAsync*?displayProperty=nameWithType> which are no longer recommended. | ||
|
|
||
| ## Rule description | ||
|
|
||
| <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException*?displayProperty=nameWithType> and <xref:Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsExceptionAsync*?displayProperty=nameWithType> are not recommended and may be deprecated in the future. | ||
|
|
||
| ## How to fix violations | ||
|
|
||
| Instead, use `Assert.ThrowsExactly` or `Assert.ThrowsExactlyAsync` instead of `Assert.ThrowsException` or `Assert.ThrowsExceptionAsync`. | ||
|
|
||
| ## When to suppress warnings | ||
|
|
||
| Do not suppress a warning from this rule. It's strongly recommended to move from the old APIs to the new ones. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| title: "MSTEST0040: Do not assert inside 'async void' contexts" | ||
| description: "Learn about code analysis rule MSTEST0040: Do not assert inside 'async void' methods, local functions, or lambdas because they may not fail the test" | ||
| ms.date: 01/17/2025 | ||
| f1_keywords: | ||
| - MSTEST0040 | ||
| - AvoidUsingAssertsInAsyncVoidContextAnalyzer | ||
| helpviewer_keywords: | ||
| - AvoidUsingAssertsInAsyncVoidContextAnalyzer | ||
| - MSTEST0040 | ||
| author: Youssef1313 | ||
| ms.author: ygerges | ||
| --- | ||
| # MSTEST0040: Do not assert inside 'async void' contexts | ||
|
|
||
| | Property | Value | | ||
| |-------------------------------------|------------------------------------------------------------------------| | ||
| | **Rule ID** | MSTEST0040 | | ||
| | **Title** | Do not assert inside 'async void' contexts | | ||
| | **Category** | Usage | | ||
| | **Fix is breaking or non-breaking** | Non-breaking | | ||
| | **Enabled by default** | Yes | | ||
| | **Default severity** | Warning | | ||
| | **Introduced in version** | 3.8.0 | | ||
| | **Is there a code fix** | No | | ||
|
|
||
| ## Cause | ||
|
|
||
| The use of any assertion method in an `async void` method, local function, or lambda. | ||
|
|
||
| ## Rule description | ||
|
|
||
| Exceptions that are thrown in an `async void` context are unobserved. So, a failing assertion in an `async void` method may go unnoticed. When using VSTest, such exceptions are very likely to be unnoticed. When using Microsoft.Testing.Platform, such exception *may* crash the process | ||
|
|
||
| ## How to fix violations | ||
|
|
||
| Refactor the code to not use assertions in `async void`. | ||
|
|
||
| ## When to suppress warnings | ||
|
|
||
| Do not suppress a warning from this rule. | ||
|
Check failure on line 41 in docs/core/testing/mstest-analyzers/mstest0040.md
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub I'll appreciate if you can review the wording for accuracy here please.
To share context: in the case of Microsoft.Testing.Platform, we do subscribe to both
TaskScheduler.UnobservedTaskExceptionandAppDomain.CurrentDomain.UnhandledExceptionand callFailFast. In VSTest, we don't subscribe.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you prevent the crashing in VSTest? Is there a SynchronizationContext that's eating the exception? Are unhandled exceptions on ThreadPool threads configured to not crash?
Exceptions in an async void method are just queued to be thrown on the current SynchronizationContext if there is one, or if there isn't on the ThreadPool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. VSTest doesn't have synchronization context. Not sure about the second question of configuring ThreadPool threads to not crash. @Evangelink @nohwnd Do you know?
@Evangelink Could it be that the test project where the original issue is noticed is setting their own synchronization context? 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look at VSTest codebase when I'm back at laptop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried a quick sample in a VSTest project. The test passes when
async voidwhich is kinda expected even for MTP, but I can see the UnhandledException being printed with VSTest.Maybe it's just about that FailFast in MTP which will simply cause non-zero exit code and things will be failing properly in CI contexts etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Original issue was on netfx so this is pretty sure it's linked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's what I meant by "Are unhandled exceptions on ThreadPool threads configured to not crash?" That setting reverts to the .NET Framework 1.x behavior circa 20 years ago where the ThreadPool eats unhandled exceptions rather than allowing them to crash the process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the following wording more accurate then?
(Note: edited after commenting)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable I'd guess. I'd find the behavior more intuitive if it behaved like xunit does: xunit registers its own SynchronizationContext in order to make
async voidwork, both in terms of knowing when the test completes and knowing when an exception occurs.async voidstill isn't recommended, but having one doesn't put the whole process in jeopardy.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub Interesting. Let me open an issue for that on our side.