なぜFluentAssertionsは内部を検証するために同等かどうか？

Question

最近、FluentAssertionsで内部オブジェクト状態の検証を避けるためにをと記載したSO questionと回答しました。今私は同じ問題に直面して、なぜ 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プロパティを除外することができます。