使用"朋友" - 单元测试的声明.馊主意？

[ 当然,问题不仅限于特定的"朋友"实现,请尽可能指出相关的实施细节 ]

通过未解答的问题,我偶然发现了这个InternalsVisibleTo属性:

指定仅在当前程序集中通常可见的类型对另一个程序集可见.

MSDN上的C#编程指南有一个Friend Assemblies部分,描述了如何使用该属性允许将方法和类型用于另一个程序集.internal

我想知道使用它来创建一个"隐藏"界面来检测库以供单元测试组件使用是否是一个好主意.它似乎在两个方向上大量增加耦合(测试生产程序集中的代码,关于测试代码中生产程序集的内部知识),但另一方面,它可能有助于创建细粒度的测试而不会混乱公共接口.

您在测试时使用好友声明的经验是什么？它是你的银色子弹,还是它开始了死亡三月？

我已经广泛使用了这种技术 - 这意味着我的单元测试可以测试普通消费者看不到的代码库的各个方面.

虽然使用[InternalsVisibleTo]确实会增加耦合,但我认为(次要)增加非常值得获得.

我的单元测试已经与测试中的代码紧密耦合 - 虽然我尝试通过访问常规消费者不可见的内容来编写确保特定结果而非特定实现的测试,但我确实在某种程度上限制了实现.

另一方面,耦合是最小的 - 在[InternalsVisibleTo]代码程序集中具有属性,并将某些内容标记为内部而不是私有(或受保护的内部而不是受保护的).

(请注意,我在这里忽略了使用单元测试引起的任何设计更改,这是一个完整的其他讨论.)

该[InternalsVisibleTo]属性需要强大的命名程序集.如果您还没有这样做,您可能会发现这有点繁琐,因为强名称程序集可能只依赖于其他强名称程序集,这可能最终导致您需要更改多个程序集.

正确获取属性可能有点繁琐,因为它需要包含测试程序集的公钥.IDesign有一个有用的Friend Assembly工具,可以在剪贴板上创建属性,为粘贴做好准备.推荐的.

这是我个人应用的唯一用途InternalsVisibleTo- 而且它确实非常非常方便.

我不认为单元测试是黑盒测试 - 它们已经在某种程度上与实现相结合.能够测试内部类型和方法可以实现更紧密的聚焦(更小的单位).