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

Может ли кто-нибудь обобщить различия и область применения между ними?

Я читал ТАК статьи,

  • ShouldBeEquivalientTo(): ShouldBeEquivalentTo() предназначен для сравнения графов сложных объектов, а не примитивных типов, являющихся частью платформы .NET.
  • Should().BeEquivalentTo(): реализация Equals() отдельных элементов для проверки эквивалентности и существует с версии 1. новая функция ShouldBeEquivalenTo(), представленная в FA 2.0, выполняет углубленное структурное сравнение, а также сообщает о любых различиях.
  • Should().Be(): не удается найти

По моему скромному пониманию, ShouldBeEquivalientTo() и Should().BeEquivalentTo() работают одинаково, если Should().BeEquivalentTo() проводит углубленное сравнение.


person Youngjae    schedule 19.09.2014    source источник
comment
Для сравнения строк ShouldBeEquivalentTo означает совпадение без учета регистра.   -  person Michael Freidgeim    schedule 19.12.2017


Ответы (1)


Я согласен, что это сбивает с толку. Should().BeEquivalentTo() на самом деле должно называться Should().EqualInAnyOrder() или что-то в этом роде. Как вы сказали, он использует реализацию Equals задействованных объектов, чтобы увидеть, все ли объекты из коллекции expected появляются в коллекции actual, независимо от порядка. Мне нужно исправить это для следующей основной версии.

person Dennis Doomen    schedule 19.09.2014
comment
Спасибо. а как насчет Should().Be()? это работает аналогично или полностью эквивалентно одному из них? - person Youngjae; 19.09.2014
comment
Есть только Should().Equal(), который делает то же самое, что и Should().BeEquivalentTo(), но требует строгого порядка. Вот почему я предлагал переименовать BeEquivalentTo в EqualInAnyOrder. - person Dennis Doomen; 19.09.2014
comment
Это было исправлено в версии 5.0. Прочитайте все об этом на continuousimprover.com/2018. /02/ - person Dennis Doomen; 06.02.2018