FluentAssertions: ShouldBeEquivalentTo vs Should().Be() vs Should().BeEquivalentTo()?

Question

Can anybody summarize differences and usage scope between them?

I read SO articles,

• ShouldBeEquivalientTo(): ShouldBeEquivalentTo() is intended to be used for comparing complex object graphs rather than the primitive types part of the .NET framework.
• Should().BeEquivalentTo(): individual items Equals() implementation to verify equivalence and has been around since version 1. The newer ShouldBeEquivalenTo() introduced in FA 2.0 is doing an in-depth structural comparison and also reporting on any differences.
• Should().Be(): cannot find.

In my humble understanding, ShouldBeEquivalientTo() and Should().BeEquivalentTo() work similar if Should().BeEquivalentTo() does in-depth comparison.

Droit

For string comparison ShouldBeEquivalentTo means case-insensitive match – Alcibiades

Answer 1

I agree this is confusing. Should().BeEquivalentTo() should actually be called Should().EqualInAnyOrder() or something like that. As you said, it uses the Equals implementation of the involved objects to see if all of the ones in the expected collection appear in the actual collection, regardless of order. I'll need to fix that for the next major version.

Loutish

Thanks. and how about Should().Be()? does it work similar or totally equivalent to one of them? – Droit

There's only Should().Equal() which does the same as Should().BeEquivalentTo() but requires strict ordering. That's why I was suggesting to rename BeEquivalentTo to EqualInAnyOrder. – Loutish

This been addressed in 5.0. Read all about it at continuousimprover.com/2018/02/… – Loutish