主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前，考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。
我偶尔发现自己需要将类中的私有方法设为public，只是为了为它编写一些单元测试。
通常这是因为该方法包含类中其他方法之间共享的逻辑，并且单独测试逻辑更整洁，或者另一个原因可能是我想测试同步线程中使用的逻辑，而不必担心线程问题。
其他人发现他们这样做是因为我不喜欢吗?我个人认为，公开一个方法的好处超过了它在类之外没有提供任何服务的问题……
更新
谢谢大家的回答，似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行，因为这是使用类的唯一方式，我非常同意这一点。在我上面提到的几个案例中，我会这样做，这是不常见的情况，我认为这样做的好处是值得的。
然而，我可以看到，每个人都指出它不应该真的发生。再仔细想想，我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具，而改变一个系统来“支持一个支持工具”是明显的坏做法。
当前回答
Guava有一个@VisibleForTesting注释，用于标记那些扩大了作用域(包或公共)的方法。我使用@Private注释来做同样的事情。
虽然必须测试公共API，但有时获取通常不是公共的东西是方便和明智的。
当:
通过将一个类分解为多个类，类的可读性会显著降低， 为了让它更容易测试， 并且提供一些对内部的测试访问就可以做到这一点
宗教似乎战胜了工程学。
其他回答
更新:我已经在其他很多地方对这个问题增加了一个更广泛、更完整的答案。这可以在我的博客上找到。
如果我需要公开一些东西来测试它，这通常暗示被测试的系统没有遵循单一责任原则。因此，应该引入一个缺失的类。将代码提取到一个新类后，将其设为public。现在您可以轻松地进行测试，并且遵循SRP。您的其他类只需通过组合调用这个新类。
使方法公开/使用语言技巧，例如将代码标记为对测试程序集可见，应该始终是最后的手段。
例如:
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
// Call Validate()
}
private void Validate()
{
// Several lines of complex code...
}
}
通过引入验证器对象重构此对象。
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
validator.Invoke(..)
}
}
现在我们要做的就是测试验证器是否被正确调用。验证的实际过程(以前的私有逻辑)可以在完全隔离的情况下进行测试。不需要复杂的测试设置来确保验证通过。
单元测试的目的是确认该单元的公共api的工作情况。应该没有必要让一个私有方法只用于测试，如果是这样，那么你的接口应该重新考虑。私有方法可以被认为是公共接口的“助手”方法，因此通过公共接口进行测试，因为它们将调用私有方法。
我认为你有这样做的“需要”的唯一原因是你的类并不是为测试而设计的。
我通常将这些方法保留为受保护的，并将单元测试放在相同的包中(但在另一个项目或源文件夹中)，在那里它们可以访问所有受保护的方法，因为类装入器将把它们放在相同的名称空间中。
为什么不把堆栈管理算法分解成一个实用程序类呢?实用程序类可以管理堆栈并提供公共访问器。它的单元测试可以集中在实现细节上。对算法复杂的类进行深度测试非常有助于消除边缘情况并确保覆盖范围。
然后，当前类可以干净地委托给实用程序类，而不暴露任何实现细节。它的测试将与其他人推荐的分页需求相关。
在java中，还可以选择将其包设置为private(即去掉可见性修饰符)。如果您的单元测试与被测试的类在同一个包中，那么它应该能够看到这些方法，并且比将方法完全公开要安全一些。
