主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前,考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。


我偶尔发现自己需要将类中的私有方法设为public,只是为了为它编写一些单元测试。

通常这是因为该方法包含类中其他方法之间共享的逻辑,并且单独测试逻辑更整洁,或者另一个原因可能是我想测试同步线程中使用的逻辑,而不必担心线程问题。

其他人发现他们这样做是因为我不喜欢吗?我个人认为,公开一个方法的好处超过了它在类之外没有提供任何服务的问题……

更新

谢谢大家的回答,似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行,因为这是使用类的唯一方式,我非常同意这一点。在我上面提到的几个案例中,我会这样做,这是不常见的情况,我认为这样做的好处是值得的。

然而,我可以看到,每个人都指出它不应该真的发生。再仔细想想,我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具,而改变一个系统来“支持一个支持工具”是明显的坏做法。


当前回答

在java中,还可以选择将其包设置为private(即去掉可见性修饰符)。如果您的单元测试与被测试的类在同一个包中,那么它应该能够看到这些方法,并且比将方法完全公开要安全一些。

其他回答

在. net中,有一个叫做PrivateObject的特殊类,专门用于允许您访问类的私有方法。

在MSDN或Stack Overflow上查看更多信息

(我很奇怪,到目前为止还没有人提到它。)

但在某些情况下,这是不够的,在这种情况下,你必须使用反射。

尽管如此,我还是会坚持不测试私有方法的一般建议,然而,像往常一样,总会有例外。

在您的更新中,您说使用公共API进行测试很好。 这里实际上有两所学校。

黑盒测试 黑盒学派认为,类应该被视为一个黑盒,没有人可以看到其中的实现。测试这一点的唯一方法是通过公共API——就像类的用户将使用它一样。 白盒测试。 白盒学派认为自然地使用关于类实现的知识,然后测试类以了解它应该工作。

在这次讨论中我真的不能支持任何一方。我只是想知道有两种不同的方法来测试一个类(或库或其他)会很有趣。

单元测试应该测试公共契约,这是在代码的其他部分使用类的唯一方法。私有方法是实现细节,你不应该测试它;只要公共API能够正常工作,实现并不重要,并且可以在不改变测试用例的情况下进行更改。

Guava有一个@VisibleForTesting注释,用于标记那些扩大了作用域(包或公共)的方法。我使用@Private注释来做同样的事情。

虽然必须测试公共API,但有时获取通常不是公共的东西是方便和明智的。

当:

通过将一个类分解为多个类,类的可读性会显著降低, 为了让它更容易测试, 并且提供一些对内部的测试访问就可以做到这一点

宗教似乎战胜了工程学。

不,因为有更好的方法来剥猫皮。

一些单元测试利用依赖于类定义中的宏,当在测试模式中构建时,这些宏会自动扩展以创建钩子。很有C风格,但是很好用。

一个更简单的OO习惯用法是使您想测试的任何东西都是“受保护的”,而不是“私有的”。测试工具继承自被测试类,然后可以访问所有受保护的成员。

或者你选择“朋友”。就我个人而言,这是我最不喜欢的c++特性,因为它打破了封装规则,但它恰好是c++实现某些特性所必需的。

无论如何,如果您正在进行单元测试,那么您很可能需要向这些成员中注入值。白盒短信是完全有效的。这真的会破坏您的封装。