@Serg046 You're unstoppable! 👍

I assume this problem also occurs for other assertions in SelfReferencingCollectionAssertions?
E.g. HaveCount which invokes Count() and passe on Subject to FailWith.

@jnyrup, yes, I can imagine that this problem exists in many places. I'd materialize the subject right after Should() call somehow so that we don't have the problem at all. But it would be a huge change that should be done separately imo.

Regarding this PR, I am just not sure how many places we should fix here. Because if we now try to find all the places, then add the tests for all of them, and finally decide to materialize the subject on an upper layer, we will just lose our prev. work. Please advise how many places this PR should affect, maybe we just check the whole SelfReferencingCollectionAssertions file for now?

@Serg046 We avoid doing any tranformations on the input and just store it directly on Subject, such that e.g. value.Should().BeSameAs(value) behaves as expected.

If I understand your proposal, you're suggesting caching the materialized collection on SelfReferencingCollectionAssertions it self, to avoid enumerating the input multiple times even for chained assertions.

myEntityCollection.Should()
    .NotBeEmpty() <-- materialize and cache `Subject`
    .And.Contain(entity) <-- reuse cached collection
    .And.NotContain(otherEntity);  <-- reuse cached collection

That approach sounds good to me.