是的，您应该在任何可能的地方测试私有方法。为什么?避免不必要的测试用例状态空间爆炸，最终只是在相同的输入上隐式地重复测试相同的私有函数。让我们用一个例子来解释为什么。

考虑一下下面略显做作的例子。假设我们想公开一个函数，该函数接受3个整数，当且仅当这3个整数都是素数时返回true。我们可以这样实现它:

public bool allPrime(int a, int b, int c)
{
  return andAll(isPrime(a), isPrime(b), isPrime(c))
}

private bool andAll(bool... boolArray)
{
  foreach (bool b in boolArray)
  {
    if(b == false) return false;
  }
  return true;
}

private bool isPrime(int x){
  //Implementation to go here. Sorry if you were expecting a prime sieve.
}

现在，如果我们采取严格的方法，只测试公共函数，我们只允许测试allPrime，而不允许测试isPrime或andAll。

作为测试人员，我们可能对每个参数的五种可能性感兴趣:< 0，= 0，= 1，质数> 1，而不是质数> 1。但为了彻底，我们还必须看看每个参数的组合是如何发挥作用的。根据我们的直觉，我们需要5*5*5 = 125个测试用例来彻底测试这个函数。

On the other hand, if we were allowed to test the private functions, we could cover as much ground with fewer test cases. We'd need only 5 test cases to test isPrime to the same level as our previous intuition. And by the small scope hypothesis proposed by Daniel Jackson, we'd only need to test the andAll function up to a small length e.g. 3 or 4. Which would be at most 16 more tests. So 21 tests in total. Instead of 125. Of course, we probably would want to run a few tests on allPrime, but we wouldn't feel so obliged to cover exhaustively all 125 combinations of input scenarios we said we cared about. Just a few happy paths.

当然，这是一个虚构的例子，但为了清晰地演示，这是必要的。这种模式可以扩展到真实的软件中。私有函数通常是最低级别的构建块，因此经常组合在一起以产生更高级别的逻辑。也就是说，在较高的层次上，由于不同的组合，我们对较低层次的东西有更多的重复。

对于从测试中调用什么api，公共和私有并不是一个有用的区分，方法和类也不是。大多数可测试单元在一个上下文中是可见的，但在其他上下文中是隐藏的。

重要的是覆盖范围和成本。您需要最小化成本，同时实现项目的覆盖目标(行、分支、路径、块、方法、类、等价类、用例……)不管团队怎么决定)。

因此，使用工具来确保覆盖率，并设计您的测试以减少成本(短期和长期)。

不要让测试变得过于昂贵。 如果只测试公共入口是最便宜的，那就这样做。 如果测试私有方法成本最低，那就这么做。

随着您的经验越来越丰富，您将能够更好地预测何时值得重构以避免测试维护的长期成本。

“我应该测试私有方法吗?”的答案是“有时.......”。通常情况下，您应该针对类的接口进行测试。

其中一个原因是您不需要对一个特性进行双重覆盖。 另一个原因是，如果您更改了私有方法，则必须为它们更新每个测试，即使对象的接口根本没有更改。

这里有一个例子:

class Thing
  def some_string
    one + two
  end

  private 

  def one
    'aaaa'
  end

  def two
    'bbbb'
  end

end


class RefactoredThing
def some_string
    one + one_a + two + two_b
  end

  private 

  def one
    'aa'
  end

  def one_a
    'aa'
  end

  def two
    'bb'
  end

  def two_b
    'bb'
  end
end

在RefactoredThing中，你现在有5个测试，其中2个你必须为重构而更新，但你的对象的功能实际上没有改变。所以让我们假设事情比这更复杂，你有一些方法来定义输出的顺序，比如:

def some_string_positioner
  if some case
  elsif other case
  elsif other case
  elsif other case
  else one more case
  end
end

这不应该由外部用户来运行，但是您的封装类可能太笨重了，无法一遍又一遍地运行这么多逻辑。在这种情况下，您可能更愿意将其提取到一个单独的类中，为该类提供一个接口并对其进行测试。

最后，假设你的主对象非常重，方法非常小你需要确保输出是正确的。你会想，“我必须测试这个私有方法!”也许你可以通过传入一些繁重的工作作为初始化参数使你的对象更轻?然后你可以放一些更轻的东西进去测试。

它不仅涉及公共或私有方法或函数，还涉及实现细节。私有函数只是实现细节的一个方面。

毕竟，单元测试是一种白盒测试方法。例如，无论谁使用覆盖率分析来识别到目前为止在测试中被忽略的代码部分，都将进入实现细节。

A)是的，你应该测试实现细节:

考虑一个排序函数，如果有多达10个元素，则出于性能考虑使用BubbleSort的私有实现，如果有超过10个元素，则使用不同排序方法(例如堆排序)的私有实现。公共API是排序函数的API。但是，您的测试套件更好地利用了实际上使用了两种排序算法的知识。

在本例中，当然可以在公共API上执行测试。然而，这需要有大量的测试用例来执行具有10个以上元素的排序函数，以便对堆排序算法进行充分的测试。这种测试用例的单独存在表明测试套件连接到功能的实现细节。

如果排序函数的实现细节发生了变化，可能是两种排序算法之间的限制发生了变化，或者堆排序被归并排序取代了，或者其他:现有的测试将继续工作。然而，它们的价值是值得怀疑的，它们可能需要重新工作，以更好地测试更改后的排序函数。换句话说，尽管测试是在公共API上进行的，但仍然需要进行维护工作。

B)如何测试实现细节

许多人认为不应该测试私有函数或实现细节的一个原因是，实现细节更有可能改变。这种更高的更改可能性至少是将实现细节隐藏在接口后面的原因之一。

现在，假设接口背后的实现包含更大的私有部分，可以选择在内部接口上进行单独的测试。有些人认为，这些部分不应该在私人的时候进行测试，它们应该变成公共的东西。一旦公开，对代码进行单元测试就可以了。

这很有趣:虽然接口是内部的，但它很可能会改变，这是一个实现细节。使用相同的接口，将其公开可以进行一些神奇的转换，即将其转换为不太可能更改的接口。显然，这种论证有一些缺陷。

但是，这背后仍然有一些事实:在测试实现细节时，特别是使用内部接口时，应该尽量使用可能保持稳定的接口。然而，某些接口是否可能是稳定的，不能简单地根据它是公共的还是私有的来确定。在我工作过一段时间的项目中，公共接口也经常发生变化，而许多私有接口多年未动。

不过，“先从正门走”是一个很好的经验法则(见http://xunitpatterns.com/Principles%20of%20Test%20Automation.html)。但请记住，这是“前门优先”，而不是“只有前门”。

C)总结

还要测试实现细节。更喜欢在稳定接口(公共或私有)上进行测试。如果实现细节发生变化，也需要修改对公共API的测试。把私人的东西变成公共的东西并不能神奇地改变它的稳定性。

我认为最好只测试对象的公共接口。从外部世界的角度来看，只有公共接口的行为是重要的，这是您的单元测试应该指向的方向。

一旦你为一个对象编写了一些可靠的单元测试，你就不希望因为接口背后的实现改变了而不得不回去修改那些测试。在这种情况下，您已经破坏了单元测试的一致性。

你也可以让你的方法包私有，即默认，你应该能够单元测试它，除非它被要求是私有的。