主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前，考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。
我偶尔发现自己需要将类中的私有方法设为public，只是为了为它编写一些单元测试。
通常这是因为该方法包含类中其他方法之间共享的逻辑，并且单独测试逻辑更整洁，或者另一个原因可能是我想测试同步线程中使用的逻辑，而不必担心线程问题。
其他人发现他们这样做是因为我不喜欢吗?我个人认为，公开一个方法的好处超过了它在类之外没有提供任何服务的问题……
更新
谢谢大家的回答，似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行，因为这是使用类的唯一方式，我非常同意这一点。在我上面提到的几个案例中，我会这样做，这是不常见的情况，我认为这样做的好处是值得的。
然而，我可以看到，每个人都指出它不应该真的发生。再仔细想想，我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具，而改变一个系统来“支持一个支持工具”是明显的坏做法。
当前回答
实际上，有些情况下你应该这样做(例如，当你实现一些复杂的算法时)。只做package-private，这就足够了。 但在大多数情况下，你可能有太复杂的类，这就需要把逻辑分解到其他类中。
其他回答
不，因为有更好的方法来剥猫皮。
一些单元测试利用依赖于类定义中的宏，当在测试模式中构建时，这些宏会自动扩展以创建钩子。很有C风格，但是很好用。
一个更简单的OO习惯用法是使您想测试的任何东西都是“受保护的”，而不是“私有的”。测试工具继承自被测试类，然后可以访问所有受保护的成员。
或者你选择“朋友”。就我个人而言，这是我最不喜欢的c++特性，因为它打破了封装规则，但它恰好是c++实现某些特性所必需的。
无论如何，如果您正在进行单元测试，那么您很可能需要向这些成员中注入值。白盒短信是完全有效的。这真的会破坏您的封装。
把它包成私有的怎么样?然后您的测试代码可以看到它(以及包中的其他类)，但它仍然对用户隐藏。
但实际上，您不应该测试私有方法。这些是实施细节，不是合同的一部分。它们所做的所有事情都应该通过调用公共方法来覆盖(如果它们的代码不是由公共方法执行的，那么应该去掉)。如果私有代码太复杂，类可能做了太多的事情，需要重构。
公开一个方法是一个很大的承诺。一旦你这样做了，人们就能使用它，你不能再改变他们了。
一些很棒的答案。我没有看到提到的一件事是，在测试驱动开发(TDD)中，私有方法是在重构阶段创建的(关于重构模式的示例，请参阅Extract Method)，因此应该已经具有必要的测试覆盖率。如果做得正确(当然，当涉及到正确性时，您将得到各种各样的意见)，您应该不必担心必须将私有方法设为公共，以便您可以测试它。
您希望单独测试的私有方法表明在您的类中隐藏了另一个“概念”。将这个“概念”提取到它自己的类中，并将其作为一个单独的“单元”进行测试。
看看这个关于这个话题的有趣视频。
我通常将测试类保持在与测试类相同的项目/程序集中。 这样，我只需要内部可见性来使函数/类可测试。
这在一定程度上使您的构建过程变得复杂，需要过滤掉测试类。 我通过将所有测试类命名为TestedClassTest并使用正则表达式筛选这些类来实现这一点。
当然，这只适用于你的问题中的c# / .NET部分
