47

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.

Community
  • 1
  • 1
Youngjae
  • 24,352
  • 18
  • 113
  • 198

1 Answers1

54

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.

Dennis Doomen
  • 8,368
  • 1
  • 32
  • 44
  • Thanks. and how about `Should().Be()`? does it work similar or totally equivalent to one of them? – Youngjae Sep 19 '14 at 07:53
  • 3
    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`. – Dennis Doomen Sep 19 '14 at 10:02
  • 4
    This been addressed in 5.0. Read all about it at http://www.continuousimprover.com/2018/02/fluent-assertions-50-best-unit-test.html – Dennis Doomen Feb 06 '18 at 10:31