主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前，考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。
我偶尔发现自己需要将类中的私有方法设为public，只是为了为它编写一些单元测试。
通常这是因为该方法包含类中其他方法之间共享的逻辑，并且单独测试逻辑更整洁，或者另一个原因可能是我想测试同步线程中使用的逻辑，而不必担心线程问题。
其他人发现他们这样做是因为我不喜欢吗?我个人认为，公开一个方法的好处超过了它在类之外没有提供任何服务的问题……
更新
谢谢大家的回答，似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行，因为这是使用类的唯一方式，我非常同意这一点。在我上面提到的几个案例中，我会这样做，这是不常见的情况，我认为这样做的好处是值得的。
然而，我可以看到，每个人都指出它不应该真的发生。再仔细想想，我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具，而改变一个系统来“支持一个支持工具”是明显的坏做法。
当前回答
You should never ever ever let your tests dictate your code. I'm not speaking about TDD or other DDs I mean, exactly what your asking. Does your app need those methods to be public. If it does then test them. If it does not then then don't make them public just for testing. Same with variables and others. Let your application's needs dictate the code, and let your tests test that the need is met. (Again I don't mean testing first or not I mean changing a classes structure to meet a testing goal).
相反，你应该“考高一点”。测试调用私有方法的方法。但是您的测试应该测试您的应用程序需求，而不是您的“实现决策”。
例如(此处为bod伪代码);
public int books(int a) {
return add(a, 2);
}
private int add(int a, int b) {
return a+b;
}
没有理由测试“add”，你可以测试“books”。
永远不要让你的测试为你做代码设计决策。测试你是否得到了预期的结果，而不是你如何得到结果。
其他回答
在java中，还可以选择将其包设置为private(即去掉可见性修饰符)。如果您的单元测试与被测试的类在同一个包中，那么它应该能够看到这些方法，并且比将方法完全公开要安全一些。
正如其他人的评论所广泛指出的那样，单元测试应该关注公共API。然而，撇开利弊和论证不考虑，您可以通过使用反射在单元测试中调用私有方法。当然，您需要确保JRE安全性允许这样做。调用私有方法是Spring框架使用它的ReflectionUtils(参见makeAccessible(Method)方法)。
下面是一个带有私有实例方法的小示例类。
public class A {
private void doSomething() {
System.out.println("Doing something private.");
}
}
以及执行私有实例方法的示例类。
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class B {
public static final void main(final String[] args) {
try {
Method doSomething = A.class.getDeclaredMethod("doSomething");
A o = new A();
//o.doSomething(); // Compile-time error!
doSomething.setAccessible(true); // If this is not done, you get an IllegalAccessException!
doSomething.invoke(o);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (SecurityException e) {
e.printStackTrace();
}
}
}
执行B，将打印正在进行私有操作。如果确实需要，可以在单元测试中使用反射来访问私有实例方法。
You should never ever ever let your tests dictate your code. I'm not speaking about TDD or other DDs I mean, exactly what your asking. Does your app need those methods to be public. If it does then test them. If it does not then then don't make them public just for testing. Same with variables and others. Let your application's needs dictate the code, and let your tests test that the need is met. (Again I don't mean testing first or not I mean changing a classes structure to meet a testing goal).
相反，你应该“考高一点”。测试调用私有方法的方法。但是您的测试应该测试您的应用程序需求，而不是您的“实现决策”。
例如(此处为bod伪代码);
public int books(int a) {
return add(a, 2);
}
private int add(int a, int b) {
return a+b;
}
没有理由测试“add”，你可以测试“books”。
永远不要让你的测试为你做代码设计决策。测试你是否得到了预期的结果，而不是你如何得到结果。
如果需要，使用反射来访问私有变量。
但实际上，您并不关心类的内部状态，您只想测试公共方法是否在您可以预期的情况下返回您所期望的内容。
在您的更新中，您说使用公共API进行测试很好。 这里实际上有两所学校。
黑盒测试 黑盒学派认为，类应该被视为一个黑盒，没有人可以看到其中的实现。测试这一点的唯一方法是通过公共API——就像类的用户将使用它一样。 白盒测试。 白盒学派认为自然地使用关于类实现的知识，然后测试类以了解它应该工作。
在这次讨论中我真的不能支持任何一方。我只是想知道有两种不同的方法来测试一个类(或库或其他)会很有趣。
