Skip to content

Revisit AssertionScope and how it travels over chained calls #2253

@dennisdoomen

Description

@dennisdoomen

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 allow methods like ContainSingle to update the Assertion instance with extra information to solve Misleading caller identity when Which fails #1502
  • 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

Metadata

Metadata

Assignees

Labels

api-suggestionEarly API idea and discussion, it is NOT ready for implementationbreaking change

Type

No type

Projects

Status

✅ Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions