Почему FluentAssertions ShouldBeEquivalentЧтобы проверить внутренности?

Question

Недавно я ответил SO question, описывая как, чтобы избежать проверки состояния внутреннего объекта в FluentAssertions. Теперь я столкнулся с той же проблемой и задавался вопросом почему ли FluentAssertions проверяет внутренние свойства OOTB?

public class Class1 
{ 
    [Fact] 
    public void CompareCultureInternalFields() 
    { 
     var foo1 = new Foo(); 
     var foo2 = new Foo(); 

     foo1.ShouldBeEquivalentTo(foo2); // fails 
    } 

    public object Culture { get; set; } 
} 

public class Foo 
{ 
    public Foo() 
    { 
     InternalProp = Guid.NewGuid(); 
    } 

    internal Guid InternalProp { get; } 
} 

Сведение об исключении:

Xunit.Sdk.XunitException: Expected member InternalProp to be {61625b04-c4e6-4e08-a45a-5ff8bb7d53e7}, but found {df589d73-e382-4104-8157-a41da2ca17f5}. 

With configuration: 
- Use declared types and members 
- Compare enums by value 
- Match member by name (or throw) 
- Be strict about the order of items in byte arrays 

не Должен foo1 и foo2 объектов быть эквивалентом для потребителя, который занимается общественной API?

Answer 1

Я попытался проследить его вплоть до истоков репо, но, судя по всему, это всегда было так. В некотором смысле, internal свойства концептуально общественный. Если вы действительно хотите создать их как не являющиеся частью вашего публичного API, сделайте их частным. Другая причина, по которой вы сталкиваетесь с этой проблемой, заключается в том, что вы проверяете область видимости на небольшой стороне. Почему бы вам сделать некоторые свойства общедоступными, а другие - внутренними? Опять же, это только презумпция со мной, и у вас могут быть веские причины для этого. Вы всегда можете исключить это свойство internal.