-
Notifications
You must be signed in to change notification settings - Fork 721
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
Provide opt-out to AssertionOptions(o => o.WithStrictOrdering())
#974
Conversation
…ucing WithoutStrictOrderingForBytes to ignore ordering of bytes.
I think we can live with the situation that byte arrays are always compared in order, irrespective to the options you provide. Do you agree @jnyrup ? |
I agree that I'm not sure about
|
I don't think we need this, do we really? |
IMHO you can't. Hence I agree that
Will do, thanks for the hint. |
@BrunoJuchli Sounds good and thanks for thinking about making |
…ForBytes() and made OrderingRuleCollection.Clear() internal.
…tStrictorderingFor(...)`.
Src/FluentAssertions/Equivalency/SelfReferenceEquivalencyAssertionOptions.cs
Outdated
Show resolved
Hide resolved
Src/FluentAssertions/Equivalency/SelfReferenceEquivalencyAssertionOptions.cs
Show resolved
Hide resolved
Breaking ChangeAs per review of @jnyrup I've introduced a breaking change. Previously:
would result in strict ordering for everything but Now the same configuration results in strict ordering for everything. Request for Decision@fluentassertions
Personally I'd like the 1st option as it's how I expected FA to behave, but of course you might have a different opinion. Also, 1st option is a breaking change, the others aren't. I wouldn't go with the 3rd option though. |
I think option 1 is the best. The order of the methods is the important part. |
I agree that option 1 is the best. I would expect the following two equivalences: .WithoutStrictOrderingFor(x => x.Foo)
.WithStrictOrdering();
// to be equivalent to
.WithStrictOrdering(); .WithStrictOrderingFor(x => x.Foo)
.WithoutStrictOrdering();
// to be equivalent to
.WithoutStrictOrdering(); We apparently only have a single test for each of |
Thanks
I'm not really sure I understand what you mean. |
To my surprise you're right. My comment about a single test was regarding the existing test coverage for variants of |
This handles #966
Added the following configuration options:
WithoutStrictOrdering()
WithoutStrictOrderingForBytes()
I'm a bit unsure about
WithoutStrictOrderingForBytes()
. Reasoning:Should
WithoutStrictOrdering()
removeByteArrayOrderingRule
? It seems likely that strict byte array ordering is almost always demanded. This poses a design-problem though. Since it's possible it was removed from the default it's not clear whether it should be present after performing:Personally, it seems risky to have
WithoutStrictOrdering
remove theByteArrayOrderingRule
. One might expect bytes still to be compared in order. And you'll only find out your expectation is wrong when a bug occurs which you believed covered by your tests...Having
WithoutStrictOrdering
always clearing theOrderingRuleCollection
and then adding aByteArrayOrderingRule
might not be expected - especially if theByteArrayOrderingRule
was not present on the default. The issue will make itself visible by throwing an exception, though.To remove the
ByteArrayOrderingRule
I could add another method to the interface (WithoutStrictOrderingForBytes
). Removing all ordering rules would then become:from a usage perspective I'd prefer this.