Question

框架AssemblyInfo.cs中的示例代码：

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
                          ("Test.Company.Department.Core")]

这是一种不好的做法吗？

Answer 1

不，这不被认为是不好的做法。没有其他办法，如果您要测试的类是出于好的原因而在您的程序集内部。只是不测试它们会更糟糕。

Answer 2

我个人认为没关系。我从未接受过“只测试公共方法”的教条。我认为还进行黑盒测试是好事，但是白盒测试可以让你通过更简单的测试来测试更多场景，特别是如果你的API合理“矮胖”并且公共方法实际上做了很多工作。

同样，在一个封装良好的项目中，您可能只有内部方法的几种内部类型。现在大概那些会产生公众影响，所以你可以只通过公共类型进行所有测试 - 但是你可能需要通过大量的实际操作来实际测试真正的东西使用InternalsVisibleTo进行简单测试。

Answer 3

我认为这样做是完全合理的。

我发现它对依赖注入非常有用。如果我有一个带有构造函数的类，它接受一些依赖项以允许它进行单元测试，我经常将其标记为内部并在我的单元测试项目中公开它。然后我有一个public（无参数，或至少参数少得多）构造函数。这样可以保持公共接口的清洁，并且仍然允许可测试的代码。

Answer 4

我会说这是一种不好的做法，因为如果您使用SOLID原理，那么您实际上就不必使用“ InternalsVisibleTo”。但是我知道在“现实世界”中您会得到各种各样的代码.....所以务实的方法是最好的。

在使用混淆的情况下，“ InternalsVisibleTo”也不理想。混淆器倾向于混淆“内部”内容。因此，任何尝试引用混淆dll内部的外部dll都将失败。您显然可以将混淆器配置为忽略外部引用的项目，但这会降低任何混淆器的有效性。

我认为，请尽量避免使用“ InternalsVisibleTo”。但是，如果您必须使用它，那么代码的结构就会出问题（您可能会从中受益很多）

Answer 5

不，正确使用时，因为在某些情况下是必要的。例如，您有单元测试A需要测试程序集B的公共成员，该成员使用在程序集B中也定义的某种内部类型。单元测试需要此类型，因此您必须使用InternalsVisibleTo。

它对保护代码也很有用。例如，一个激活程序集。您可能只希望解决方案中的一个模块访问您的激活程序集，并阻止任何人添加对它的引用和调用方法。您可以将类型和成员设置为内部，仅将它们公开给具有公钥标记的已签名程序集，并将其隐藏在世界其他地方。

Answer 6

如果您需要测试不希望公开的API的子部分，

InternalsVisibleTo可能会有用。

但是，通过公共API进行测试更为可取，因为它可以更轻松地重构内部API。请谨慎使用InternalsVisibleTo，并且仅在适当时使用{{1}}，例如API的大小很重要。