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


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

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

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

更新

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

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


当前回答

许多答案建议只测试公共接口,但恕我直言,这是不现实的——如果一个方法执行的操作需要5个步骤,那么您将希望分别测试这5个步骤,而不是一起测试。这需要测试所有五个方法,否则它们(除了测试之外)可能是私有的。

测试“私有”方法的通常方法是给每个类一个自己的接口,并将“私有”方法设为公共的,但不将它们包含在接口中。这样,它们仍然可以被测试,但不会使界面膨胀。

是的,这将导致文件和类膨胀。

是的,这确实使公共和私有说明符变得多余。

是啊,这真让人头疼。

不幸的是,这是我们为使代码可测试而做出的众多牺牲之一。也许未来的语言(或者甚至是c# /Java的未来版本)将具有使类和模块可测试性更加方便的特性;但与此同时,我们得跳过这些障碍。


There are some who would argue that each of those steps should be its own class, but I disagree - if they all share state, there is no reason to create five separate classes where five methods would do. Even worse, this results in file- and class-bloat. Plus, it infects the public API of your module - all those classes must necessarily be public if you want to test them from another module (either that, or include the test code in the same module, which means shipping the test code with your product).

其他回答

私有方法通常用作“助手”方法。因此,它们只返回基本值,从不操作对象的特定实例。

如果您想测试它们,您有几个选项。

使用反射 给这些方法包访问权

或者,如果helper方法是一个足够好的新类候选,您可以使用它作为公共方法创建一个新类。

这里有一篇很好的文章。

最近,当重构一个大方法(> 200行)时,我也有同样的想法。对于每个逻辑步骤,我成功地将大方法拆分为较小的方法,因此很容易进行推理。

当涉及到重构出来的小型私有方法时,我想知道我是否应该单独测试它们,因为如果我只测试公共方法,我仍然在测试大方法,测试根本没有从重构中受益

经过一番思考,我意识到:

if all the small methods are private and can't be reused by others, maybe I am doing something wrong: I am not pulling the right abstraction from the code, I am only splitting the big methods treating them like lines/strings, not like mental barrier when I came to the right small methods(I refactored again, completely changing the small methods), and move the small methods into another class exposed as public methods for others to use, now I can test them(and I should test them, they will be used more and deserver the attention)

简介:

我仍然有很多小的私有方法,但是它们共享了很多公共方法,而且小方法真的很小(3-4行,主要是函数调用),但我不会测试它们,我只需要在另一个类中测试共享的公共方法

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

把它包成私有的怎么样?然后您的测试代码可以看到它(以及包中的其他类),但它仍然对用户隐藏。

但实际上,您不应该测试私有方法。这些是实施细节,不是合同的一部分。它们所做的所有事情都应该通过调用公共方法来覆盖(如果它们的代码不是由公共方法执行的,那么应该去掉)。如果私有代码太复杂,类可能做了太多的事情,需要重构。

公开一个方法是一个很大的承诺。一旦你这样做了,人们就能使用它,你不能再改变他们了。

我想说这是一个坏主意,因为我不确定你是否会得到任何好处,并可能出现问题。如果你改变一个调用的契约,只是为了测试一个私有方法,你并不是在测试这个类将如何使用它,而是在创建一个你从未打算发生的人为场景。

此外,通过将方法声明为公共,在六个月的时间内(在忘记将方法公开的唯一原因是为了测试之后),您(或者如果您已经移交了项目)完全不同的人将不会使用它,从而导致潜在的意想不到的后果和/或维护噩梦。