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

Question

Mam test, który sprawdza wyjście kolekcji metody. Ta odmiana testu przechodzi:

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

     Sut.GetUnprocessedStatuses() 
      .Should() 
      .BeEquivalentTo(expectedUnprocessedStatuses); 
    } 

Ta odmiana test nie powiedzie się, z błędem "Oczekiwany element [0], aby być procesowa, ale okazało pending":

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

     Sut.GetUnprocessedStatuses() 
      .ShouldBeEquivalentTo(expectedUnprocessedStatuses); 
    } 

wyraźnie ShouldBeEquivalentTo troski o zbiorze pozycji zamówienia, natomiast BeEquivalentTo nie. Dlaczego pojęcie równoważności różni się między dwiema metodami?

Answer 1

Masz rację. Powinien(). BeEquivalentTo() używa poszczególnych elementów do implementacji Equals() w celu sprawdzenia równoważności i istnieje od wersji 1. Nowsza metoda ShouldBeEquivalentTo() wprowadzona w FA 2.0 dokonuje dogłębnego porównania strukturalnego, a także raportuje wszelkie różnice . W wersji 2.1 zamierzam zmienić zachowanie tak, aby był bardziej podobny do domyślnej kolekcji