如果您不测试您的私有方法，您怎么知道它们不会崩溃呢?

如果私有方法定义良好(即，它有一个可测试的函数，并且不会随着时间的推移而改变)，那么是的。我在有意义的地方测试所有可测试的东西。

例如，加密库可能会隐藏这样一个事实，即它使用一次仅加密8个字节的私有方法执行块加密。我会为此写一个单元测试——它并不意味着要改变，即使它是隐藏的，如果它真的坏了(例如，由于未来的性能增强)，那么我想知道是私有函数坏了，而不仅仅是某个公共函数坏了。

它加快了以后的调试。

亚当

我看到很多人都有同样的想法:在公共层面上进行测试。但这不正是我们的QA团队所做的吗?他们测试输入和预期输出。如果作为开发人员，我们只测试公共方法，那么我们只是在重做QA的工作，而不是通过“单元测试”来增加任何价值。

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

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

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

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

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

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

B)如何测试实现细节

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

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

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

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

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

C)总结

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

不，你不应该测试私有方法，为什么?此外，流行的mock框架(如Mockito)不支持测试私有方法。

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

考虑一下下面略显做作的例子。假设我们想公开一个函数，该函数接受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.

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