在框架的 AssemblyInfo.cs
中的示例代码:
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
("Test.Company.Department.Core")]
这是一种不好的做法吗?
在框架的 AssemblyInfo.cs
中的示例代码:
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
("Test.Company.Department.Core")]
这是一种不好的做法吗?
不,这并不被认为是不良做法。如果你想测试的类在你的程序集中是有充分理由是内部类,那么没有其他方法。不测试它们会更糟糕。
就我个人而言,我认为这样做是可以的。我从来没有遵循“仅测试公共方法”的教条。我认为黑盒测试也是有好处的,但白盒测试可以让你使用更简单的测试来测试更多的场景,特别是当你的API比较“厚重”且公共方法实际上需要完成很多工作时。
同样,在一个完全封装的项目中,您可能会有几种只有内部方法的内部类型。现在假设这些类型将产生公共影响,因此您可以通过公共类型进行所有测试。但是,如果您使用InternalsVisibleTo
,那么您可以使用非常简单的测试来测试某些东西,而不需要经过很多麻烦。
InternalsVisibleTo
可以在您不想公开的情况下测试 API 的子部分,这很有用。
然而,通过公共 API 进行测试更可取,因为它使重构内部 API 更加容易。使用 InternalsVisibleTo
要谨慎,只在适当的时候使用,例如 API 的规模相当大。
我认为这样做是完全合理的。
我发现这对于依赖注入非常有用。如果我有一个带有几个依赖项的构造函数的类,以允许进行单元测试,我经常将其标记为内部,并在我的单元测试项目中公开它。然后我会有一个公共(无参数,或至少参数更少)构造函数。这使得公共接口保持清洁,同时仍允许进行可测试的代码。
不是的,当使用正确时,因为在某些情况下它是必要的。例如,您有一个单元测试A
需要测试程序集B
中使用一些内部类型的公共成员。单元测试需要这个类型,因此您必须使用InternalsVisibleTo
。
它还可以用于保护代码。例如,激活程序集。您可能只希望解决方案中的一个模块访问您的激活程序集,并防止任何人添加对其的引用并调用方法。您可以将类型和成员设置为内部,仅向具有公钥标记的已签名程序集公开它们,从而使其对世界其他地方隐藏。
InternalsVisibleTo
。否则,请使用公共 API。 - Daniel Hilgarth