主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前，考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。
我偶尔发现自己需要将类中的私有方法设为public，只是为了为它编写一些单元测试。
通常这是因为该方法包含类中其他方法之间共享的逻辑，并且单独测试逻辑更整洁，或者另一个原因可能是我想测试同步线程中使用的逻辑，而不必担心线程问题。
其他人发现他们这样做是因为我不喜欢吗?我个人认为，公开一个方法的好处超过了它在类之外没有提供任何服务的问题……
更新
谢谢大家的回答，似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行，因为这是使用类的唯一方式，我非常同意这一点。在我上面提到的几个案例中，我会这样做，这是不常见的情况，我认为这样做的好处是值得的。
然而，我可以看到，每个人都指出它不应该真的发生。再仔细想想，我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具，而改变一个系统来“支持一个支持工具”是明显的坏做法。
当前回答
在java中，还可以选择将其包设置为private(即去掉可见性修饰符)。如果您的单元测试与被测试的类在同一个包中，那么它应该能够看到这些方法，并且比将方法完全公开要安全一些。
其他回答
就我个人而言，我宁愿使用公共API进行单元测试，我当然不会为了方便测试而将私有方法设为公共。
如果您真的想单独测试私有方法，那么在Java中可以使用Easymock / Powermock来实现这一点。
你必须务实，你也应该意识到为什么事情很难测试的原因。
“倾听测试”——如果测试很困难，这是否能告诉你关于你的设计的一些东西?你能不能重构到这样一个地方，对这个方法的测试将是微不足道的，并且很容易通过公共api进行测试?
以下是Michael Feathers在《有效使用遗留代码》一书中所说的话
“很多人花了很多时间试图弄清楚如何解决这个问题……真正的答案是，如果你想测试一个私有方法，这个方法不应该是私有的;如果公开方法让您感到困扰，很可能是因为它是单独责任的一部分;它应该上另一门课。”[有效地使用遗留代码(2005)，作者:M. Feathers]
如果你正在使用c#，你可以让方法是内部的。这样就不会污染公共API。
然后将属性添加到dll
[组装:InternalsVisibleTo(“MyTestAssembly”)]
现在所有的方法都在MyTestAssembly项目中可见。也许不完美，但总比为了测试而将私有方法设为公共要好。
我倾向于认为进行单元测试所带来的好处超过了增加某些成员曝光度所带来的问题。稍微改进一下，将其设置为受保护的虚拟对象，然后在测试类中覆盖它以公开它。
或者，如果你想单独测试它的功能，它是否表明你的设计中缺少一个对象?也许你可以把它放在一个单独的可测试类中……那么你现有的类只是委托给这个新类的一个实例。
一些很棒的答案。我没有看到提到的一件事是，在测试驱动开发(TDD)中，私有方法是在重构阶段创建的(关于重构模式的示例，请参阅Extract Method)，因此应该已经具有必要的测试覆盖率。如果做得正确(当然，当涉及到正确性时，您将得到各种各样的意见)，您应该不必担心必须将私有方法设为公共，以便您可以测试它。
在我看来，在编写测试时，你不应该对你的类内部是如何实现的做深入的假设。您可能希望稍后使用另一个内部模型对其进行重构，但仍然保证与以前的实现相同。
记住这一点，我建议你把重点放在测试你的契约仍然存在，不管你的类目前有什么内部实现。基于属性的公共api测试。
