You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although I'm still thinking about the design, I propose the following changes:
AssertionScope is only used by consumers as they do now and by certain APIs such as BeEquivalentTo
Every Should method will create a new object called Assertion (but I'm open to a better name) that contains the context of the assertion and a link to the scope. When no ambient AssertionScope is available, it will be a new one that is created at that point. This is different from v6 where we create a new scope per call to Execute.Assertion.
Every Should method will also take an extra parameter annotated with [CallerArgumentExpression]. If this returns a non-null value, we can use that instead of using the CallerIdentifier.
This Assertion instance will be explicitly passed to all the assertion classes (like StringAssertions).
No public APIs will depend on AssertionScope.Current anymore
Most of the APIs that are now part of AssertionScope will need to move to Assertion.
This should also allow us to drop ClearExpectations
Also provides a nice split between the responsibility of AssertionScope as a way to group related assertions and its responsibilities as the internal assertion API
Perhaps related to this idea:
Use [CallerArgumentExpression] to retrieve the name of the subject at compile-time and populate this Assertion object with that.
The idea is to remove the need for CallerIdentifier, which is both slow and fragile.
Yeah, that could work indeed. And in case it doesn't work (.NET 6 SDK not installed and using .NET Framework 4.7), we can fall back to the CallerIdentifier.
The first attempt where Which would return a WhichResult that includes both the result as well as the current assertion failed for a couple of reasons. But sometimes we directly call methods or access properties on the result of Which, which means the type of what Which returns must be TElement. So trying to pass a compound object from one Should to another through a special AndWhichConstraint was more difficult than I thought.
Although I'm still thinking about the design, I propose the following changes:
AssertionScope
is only used by consumers as they do now and by certain APIs such asBeEquivalentTo
Should
method will create a new object calledAssertion
(but I'm open to a better name) that contains the context of the assertion and a link to the scope. When no ambientAssertionScope
is available, it will be a new one that is created at that point. This is different from v6 where we create a new scope per call toExecute.Assertion
.Should
method will also take an extra parameter annotated with[CallerArgumentExpression]
. If this returns a non-null
value, we can use that instead of using theCallerIdentifier
.Assertion
instance will be explicitly passed to all the assertion classes (likeStringAssertions
).AssertionScope.Current
anymoreAssertionScope
will need to move toAssertion
.ContainSingle
to update theAssertion
instance with extra information to solve Misleading caller identity whenWhich
fails #1502ClearExpectations
AssertionScope
as a way to group related assertions and its responsibilities as the internal assertion APIhttps://www.fluentassertions.com
The text was updated successfully, but these errors were encountered: