FluentAssertions ShouldBeEquivalentTo () versus Should (). BeEquivalentTo ()

Question

I have a test that checks the output of a method collection. This test option passes:

[TestMethod, TestCategory("BVT")] public void TheStatusesAreReturned() { var expectedUnprocessedStatuses = new List<FileUploadStatus> { FileUploadStatus.InProcess, FileUploadStatus.Pending, }; Sut.GetUnprocessedStatuses() .Should() .BeEquivalentTo(expectedUnprocessedStatuses); } 

This test variation fails, and the error "Expected element [0] will be InProcess, but Waiting found":

  [TestMethod, TestCategory("BVT")] public void TheStatusesAreReturned2() { var expectedUnprocessedStatuses = new List<FileUploadStatus> { FileUploadStatus.InProcess, FileUploadStatus.Pending, }; Sut.GetUnprocessedStatuses() .ShouldBeEquivalentTo(expectedUnprocessedStatuses); } 

Clearly, ShouldBeEquivalentTo takes care of the order in which items are collected, while BeEquivalentTo does not. Why is the concept of equivalence different from two methods?

Answer 1

You're right. Must () BeEquivalentTo () uses separate Equals () elements to verify equivalence and has existed since version 1. The newest ShouldBeEquivalentTo (), introduced in FA 2.0, makes a deep structural comparison and also reports any differences. For 2.1, I'm going to change the behavior, to be like default collection equivalence.