为什么 FluentAssertions ShouldBeEquivalentTo 验证内部？答案

【问题标题】：Why does FluentAssertions ShouldBeEquivalentTo validate internals?为什么 FluentAssertions ShouldBeEquivalentTo 验证内部？
【发布时间】：2017-06-15 10:47:36
【问题描述】：

最近我在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

对于处理公共 API 的消费者，foo1 和 foo2 对象是否应该等效？

【问题讨论】：

在您的示例中，如果该类位于另一个程序集/项目中，您应该无法访问内部属性。如果类在同一个程序集中，这不是一个很好的例子
好点。如果我用一些自动生成的内部字段重写示例怎么办？
好吧，我明白你的意思了。
我将InternalProp 设为只读。现在它只存储一些自动生成的值，这些值应该可以解决您对“跨项目”访问的担忧。现在看起来更正确了吗？
这是 FluentAssertions 的作者做出的选择。除了作者，没有人能回答他们为什么做出这样的选择。我认为这是一个不错的选择吗？这是一个意见问题，这里不是讨论意见的地方。

标签： c# tdd fluent-assertions

【解决方案1】：

我试图一直追溯到回购的起源，但显然它一直是这样的。在某种程度上，internal 属性在概念上是public。如果您真的想将它们设计为不属于您的公共 API 的一部分，请将它们设为私有。您可能会遇到此问题的另一个原因是您正在测试的范围可能有点小。为什么要公开一些属性而将其他属性设为内部？同样，这只是我的一个假设，您可能有充分的理由这样做。不过，您始终可以排除 internal 属性。

【讨论】：