Java 将成员公开以进行单元测试

我知道有很多关于类内私有成员的单元测试的问题。他们中的大多数人得出的结论是，拥有需要测试的私有成员是一种需要重构的设计缺陷（例如，请参阅）。不过，我还有最后一个问题：

当我将我的私有成员重构为新类时，它们将成为（公共）API成员，但这是我想要避免的。因此，通过简化我们的客户机类，我们通过设计一个新的公开可见的助手类来处理我们的API。当然，也可以在程序集中编写测试代码，并将这些助手设置为内部的，但这样我们也可以将测试代码发送到生产站点

我认为这个问题没有正确的答案，但也许你有一些很好的想法可以帮助避免这些情况？

关于C，你可以尝试最后一个技巧

使您的

类

/members

内部

在要测试的程序集中，打开AssemblyInfo.cs文件，并通过添加以下属性使内部构件对测试项目/程序集可见：

[内部可视（“您的测试项目”）]

这会使您的成员在程序集外部不可见，除非是为了在“YourTestProject”-程序集中进行测试

---

可以找到有关此属性的更多信息。

我计划将此作为编辑撰写，但我得出的结论是，我对这些问题做出了错误的假设。我想我的问题是我把要测试的内容和如何测试混为一谈

测试内容：做了一定量值得测试的工作的成员访问修饰符在此处不起任何作用

如何测试：对公众成员没有问题；然而，对私人成员有点棘手，但可行的，正如在上面的答案看到的

---

话虽如此，正确的方法是将相关成员提取到新的非公共助手类中。为了能够测试这些成员（尽管不是公开的），我们使用前面提到的任何方法，反射、

InternalsVisibleTo

甚至（在某些时候使用反射）

总之，不要为了可测试性而破坏/污染代码。我宁愿使用反射（如上面的链接）来测试私有方法，以确保没有任何东西被破坏。它是“丑陋的”。。。但效果很好。我宁愿有一辆运行良好的丑陋的汽车，然后是一辆随时可能在没有任何警告的情况下爆炸的法拉利。我真的不明白使用反射进行单元测试有什么错。您正在处理的不是生产代码，有时对私有方法进行单元测试是有意义的。我建议不要测试私有方法。通过公共api测试它们。请看，虽然这并没有污染API，但它仍然通过扩展其成员的访问权限来更改实际的类设计，只是为了测试。不过，我想这在大多数情况下都是可以的。