主持人注:这里已经有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”。
永远不要让你的测试为你做代码设计决策。测试你是否得到了预期的结果，而不是你如何得到结果。
其他回答
为什么不把堆栈管理算法分解成一个实用程序类呢?实用程序类可以管理堆栈并提供公共访问器。它的单元测试可以集中在实现细节上。对算法复杂的类进行深度测试非常有助于消除边缘情况并确保覆盖范围。
然后，当前类可以干净地委托给实用程序类，而不暴露任何实现细节。它的测试将与其他人推荐的分页需求相关。
注意: 这个答案最初是针对以下问题发布的:单独的单元测试是否是通过getter公开私有实例变量的好理由?这是合并到这个，所以它可能是一个特定于这里提出的用例。
一般来说，我通常都支持重构“生产”代码，以使其更容易测试。然而，我不认为这是一个好的决定。一个好的单元测试(通常)不应该关心类的实现细节，只关心它的可见行为。与其将内部堆栈暴露给测试，不如测试类在调用first()或last()后是否按照预期的顺序返回页面。
例如，考虑以下伪代码:
public class NavigationTest {
private Navigation nav;
@Before
public void setUp() {
// Set up nav so the order is page1->page2->page3 and
// we've moved back to page2
nav = ...;
}
@Test
public void testFirst() {
nav.first();
assertEquals("page1", nav.getPage());
nav.next();
assertEquals("page2", nav.getPage());
nav.next();
assertEquals("page3", nav.getPage());
}
@Test
public void testLast() {
nav.last();
assertEquals("page3", nav.getPage());
nav.previous();
assertEquals("page2", nav.getPage());
nav.previous();
assertEquals("page1", nav.getPage());
}
}
在您的更新中，您说使用公共API进行测试很好。 这里实际上有两所学校。
黑盒测试 黑盒学派认为，类应该被视为一个黑盒，没有人可以看到其中的实现。测试这一点的唯一方法是通过公共API——就像类的用户将使用它一样。 白盒测试。 白盒学派认为自然地使用关于类实现的知识，然后测试类以了解它应该工作。
在这次讨论中我真的不能支持任何一方。我只是想知道有两种不同的方法来测试一个类(或库或其他)会很有趣。
我倾向于认为进行单元测试所带来的好处超过了增加某些成员曝光度所带来的问题。稍微改进一下，将其设置为受保护的虚拟对象，然后在测试类中覆盖它以公开它。
或者，如果你想单独测试它的功能，它是否表明你的设计中缺少一个对象?也许你可以把它放在一个单独的可测试类中……那么你现有的类只是委托给这个新类的一个实例。
我经常会在类中添加类似validate、verify、check等方法，这样就可以调用它来测试对象的内部状态。
有时这个方法被包装在一个ifdef块中(我主要是用c++写的)，这样它就不会被编译发布。但是在发行版中，提供遍历程序对象树检查内容的验证方法通常是有用的。
