主持人注:这里已经有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).
您希望单独测试的私有方法表明在您的类中隐藏了另一个“概念”。将这个“概念”提取到它自己的类中，并将其作为一个单独的“单元”进行测试。
看看这个关于这个话题的有趣视频。
在我看来，在编写测试时，你不应该对你的类内部是如何实现的做深入的假设。您可能希望稍后使用另一个内部模型对其进行重构，但仍然保证与以前的实现相同。
记住这一点，我建议你把重点放在测试你的契约仍然存在，不管你的类目前有什么内部实现。基于属性的公共api测试。
实际上，有些情况下你应该这样做(例如，当你实现一些复杂的算法时)。只做package-private，这就足够了。 但在大多数情况下，你可能有太复杂的类，这就需要把逻辑分解到其他类中。
如果你正在使用c#，你可以让方法是内部的。这样就不会污染公共API。
然后将属性添加到dll
[组装:InternalsVisibleTo(“MyTestAssembly”)]
现在所有的方法都在MyTestAssembly项目中可见。也许不完美，但总比为了测试而将私有方法设为公共要好。
