共识似乎是在做 TDD 时不要测试私有方法。
我一直在遇到同样的情况。我有一个私有方法（例如，它将所有选项都关闭）。它改变了很多状态，并被一些公共方法调用。无论调用哪个公共方法（所有选项都设置为关闭），私有方法对状态所做的更改都将保持不变。
在不添加许多有效地做同样事情的测试的情况下，测试这个私有方法的功能的最佳方法是什么？
顺便说一句，我正在使用 QUnit 来测试 Javascript 对象。
这是我的课的一个过于简化的版本。
http://jsfiddle.net/twistedinferno/UMgAx/
编辑
我在这里真正想问的不是“我应该还是不应该测试私有方法”，因为这已经得到了回答，而答案是否定的。我想知道如何最好地测试每个公共方法，记住由于使用了我的私有方法，许多断言将是相同的。许多公共方法调用相同的私有方法。是否可以有很多重复的断言来测试当许多公共方法中的每一个调用我的私有方法时发生的状态变化？
测试公共方法。
或者，更一般地，测试对象的外部可见界面。
如果私有方法被公共方法使用，它的使用将被测试作为结果。但是私有方法本身是私有的，与该对象之外的任何东西（包括测试）无关。
这些测试不应该知道或关心这样的私有方法是否存在，更不用说他们是否正在测试它。他们应该测试所有公共功能。
如果许多测试都在做同样的事情，这是否表明公共功能中存在不必要的重叠？也许那里有重构的空间？当然，这完全是猜测，没有看到任何代码。你能举个例子吗？
编辑
额外的断言重复了相同的击键，但测试明显不同，因为它们正在测试不同的面向外部的功能。您始终可以将重复的断言重构为每个测试调用的单个函数。一种自定义聚合断言。只要公共方法继续具有相同的可观察（和可测试）行为，那就没问题了。一旦改变，它的测试当然也需要改变。
鉴于您正在练习 TDD，我假设如果没有需要编写的测试，所讨论的私有方法中的每一行代码都不会存在。这意味着不需要独立于公共接口测试私有函数。
谢谢！
布兰登
我同意 bcariso 和 David 的观点。你不应该测试，也不应该测试私有方法。
需要注意的一点是，如果您的私有方法如此庞大和重要，以至于您觉得必须对其进行测试，您应该考虑将其提取为它自己的辅助类的公共方法。
在 Javascript 中，原则相同，只是您将其设为公开可见的函数或模块（如果您使用该模式）。