使用“友元”声明进行单元测试。坏主意?

我已经广泛使用了这种技术——这意味着我的单元测试可以测试代码库中普通用户看不到的方面。

使用时 [InternalsVisibleTo] 确实增加了耦合,我相信(微小的)增加是值得的。

另一方面,耦合是最小的——在 [内部可视] 属性,并将某些内容标记为 而不是 私有的 (或 保护内部 受保护的

(请注意,这里我忽略了由于使用单元测试而引起的任何设计更改,这是一个完全不同的讨论。)

[内部可视] 属性要求对程序集进行强命名。如果您还没有这样做,您可能会发现这有点麻烦,因为强名称程序集可能只依赖于其他强名称程序集,这可能会导致您需要更改多个程序集。

获取正确的属性可能有点麻烦,因为它需要包含测试程序集的公钥。思想设计有一个有用的方法 Friend Assembly tool 在剪贴板上创建属性,准备粘贴。推荐。

这是我个人申请的唯一用途 InternalsVisibleTo -它确实非常非常方便。

我不认为单元测试是黑盒测试——它们在某种程度上已经与实现耦合在一起了。能够测试内部类型和方法允许更紧密地关注(更小的单元)。

我认为使用 InternalsVisibleToAttribute internal I don't want to unit test private methods 虽然

然而,我的偏好是将单元测试与生产代码放在同一个程序集中。它通常不会影响我的客户,但它确实为我简化了事情,所以我就这么做了。当我这样做的时候,它使 InternalsVisibleTo 问题走开。

只有 使用我能让自己使用的 InternalsVisibleToAttribute 对于有了它,您可以将“私有”方法的很大一部分实现为内部方法,而不是将它们公开给单元测试框架,以便对类内部不变量进行更具侵入性的测试。

我在这项技术上取得了巨大的成功。如果没有其他帮助的话,它可以让您在无法访问的情况下调用私有方法,从而帮助您实现神话般的100%代码覆盖率目标。

我们已经将C++程序集转换为C++/CLI,然后在C语言中实现新的代码。当我们这样做时,我们仍然会对C#中并非真正公开的类/方法使用“internal”,然后将它们作为友元程序集提供给遗留代码。