在单元测试代码中使用InternalsVisibleTo被认为是不好的做法吗?
本文关键字：认为是 代码 单元测试 InternalsVisibleTo | 更新日期: 2023-09-27 18:09:59
框架AssemblyInfo.cs的示例代码:
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
("Test.Company.Department.Core")]
这是一个不好的做法吗?
不，这不是不好的做法。如果您有充分的理由要测试的类是程序集的内部类，则没有其他方法。如果不进行测试，情况会更糟。
我个人认为这很好。我从来不赞同"只测试公共方法"的教条。我认为也有黑盒测试是很好的，但是白盒测试可以让你用更简单的测试测试更多的场景，特别是如果你的API相当"厚实"并且公共方法实际上做了很多工作。
同样，在一个封装良好的项目中，您可能有几个内部类型，其中只有内部方法。现在假设这些将有公共影响，所以你可以通过公共类型做所有的测试-但是你可能需要通过很多的环来实际测试一些真的很容易用InternalsVisibleTo测试的东西。
InternalsVisibleTo可能是有用的，如果你需要测试你的API的子部分，你不想暴露。
然而，通过公共API进行测试是可取的，因为它使重构内部API更容易。谨慎使用InternalsVisibleTo，仅在适当的时候使用，例如，API的大小是重要的。
我认为这样做是完全合理的。
我发现它对依赖注入非常有用。如果我有一个带有构造函数的类，它接受了一些依赖项以允许它进行单元测试，我通常会将其标记为内部并在单元测试项目中公开它。然后我将有一个公共(无参数，或者至少参数少得多)构造函数。这保持了公共接口的整洁，并且仍然允许可测试的代码。
如果使用正确，则不需要，因为在某些情况下它是必要的。例如，您有一个单元测试A，它需要测试程序集B的一个公共成员，该成员使用了程序集B中定义的一些内部类型。单元测试需要这种类型，因此您必须使用InternalsVisibleTo。
对于保护代码也很有用。例如，激活程序集。您可能只希望解决方案中的一个模块访问激活程序集，并防止任何人向其添加引用和调用方法。您可以将类型和成员设置为内部，仅将它们公开给带有公钥令牌的签名程序集，并将其对其他部分隐藏。
我会说这是不好的做法，因为如果你已经使用了SOLID原则，那么你真的不应该使用"internalsvisible "然而我知道在"现实世界"中你会得到各种各样的代码.....因此，务实的方法是最好的。
也"InternalsVisibleTo"在使用混淆的场景中并不理想。混淆器倾向于混淆"内部"。的东西。因此，任何试图引用被混淆的dll内部的外部dll都将失败。显然，您可以将混淆器配置为忽略外部引用的项，但这会降低任何混淆器的有效性。
在我看来，避免使用"InternalsVisibleTo"如果可以的话。但是如果你必须使用它，那么代码的结构就有问题(你往往会得到很多)。