-
Notifications
You must be signed in to change notification settings - Fork 734
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
Introduced Assert.EnterMultipleScope #4758
Conversation
acaf638
to
4dee383
Compare
This is now ready for review. |
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.
Thanks @manfred-brands this looks great.
I have two questions about edge case behaviours on the new scope.
} | ||
|
||
[Test] | ||
public void ScopeReleasedOutOfOrder() |
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.
request: Can we also add a test for double-disposing a scope? I think the existing logic in AssertionScope
will catch this and fail but it would be good to have coverage for our desired behaviour to prevent accidental changes in the future.
related question: Should it fail if we dispose the same scope twice, or should the second be a no-op? I know CA2202 warns against disposing multiple times, but the docs there also mention
A correctly implemented Dispose method can be called multiple times without throwing an exception. However, this is not guaranteed
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.
@stevenaw Good point!
I went for not throwing an error as multiple calls to Dispose
should be safe as per the interface specification remarks.
If an object's Dispose method is called more than once, the object must ignore all calls after the first one. The object must not throw an exception if its Dispose method is called multiple times.
The CA2202 is deprecated and no longer in the latest analyzer nuget package.
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.
Thanks! I had somehow glossed over the part of the documentation where it said the rule was deprecated.
@@ -47,7 +47,10 @@ public override TestResult Execute(TestExecutionContext context) | |||
if (_testMethod.HasExpectedResult) | |||
Assert.That(result, Is.EqualTo(_testMethod.ExpectedResult)); | |||
|
|||
context.CurrentResult.SetResult(ResultState.Success); | |||
if (context.MultipleAssertLevel > 0) |
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.
question: Should we dispose of any open scopes here after reporting the error? I'm not sure if there could be any stability issues with leaving them around given they themselves contain a reference to a particular TestExecutionContext
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.
We cannot as we don't have a reference to them. I don't think it is worth it to add them as references to the context.
Every test gets it own new context and the old scope and context will be garbage collected.
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.
Ok sounds good. My thinking had indeed been probing if it made sense to track these on the context as a Stack<AssertionScope>
instead of the MultipleAssertLevel
counter, but as you say we can also fulfill the behaviour without doing those broader changes.
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.
This looks good to me, thanks @manfred-brands .
Not sure if you were in a rush to merge or wanted to see if others had thoughts
Lgtm, so I'll just merge it. |
Fixes #4587