绝对是的。这就是单元测试的要点，你测试单元。私有方法是一个单元。没有测试私有方法，TDD(测试驱动开发)是不可能的，

我已经为这个问题苦恼了一段时间，尤其是在尝试TDD的时候。

我曾经看到过两篇文章，我认为它们在TDD的情况下已经足够彻底地解决了这个问题。

测试私有方法，TDD和测试驱动重构 测试驱动开发不是测试

总而言之:

当使用测试驱动开发(设计)技术时，私有方法应该只在重构已经工作和测试过的代码的过程中出现。 根据这个过程的本质，任何从经过彻底测试的功能中提取出来的简单实现功能都将是自我测试的(即间接测试覆盖率)。

对我来说，在编码的开始部分，大多数方法都是高级函数，因为它们封装/描述了设计。

因此，这些方法将是公开的，并且测试它们将非常容易。

私有方法将在一切正常工作后出现，并且为了可读性和清洁度我们正在进行重构。

其中一个要点是

如果我们测试以确保逻辑的正确性，并且私有方法携带逻辑，那么我们应该测试它。不是吗?我们为什么要跳过这个呢?

基于方法的可见性编写测试是完全无关的想法。

相反

另一方面，在原始类之外调用私有方法是一个主要问题。在一些模拟工具中，模拟私有方法也有局限性。(例:5)

虽然有一些工具如Power Mock支持这一点，但这是一个危险的操作。原因是它需要破解JVM来实现这一点。

一种可以解决的方法是(如果您想为私有方法编写测试用例)

将这些私有方法声明为受保护的。但在某些情况下可能不方便。

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

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

这里有一个例子:

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

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

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

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

考虑一下下面略显做作的例子。假设我们想公开一个函数，该函数接受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，公共和私有并不是一个有用的区分，方法和类也不是。大多数可测试单元在一个上下文中是可见的，但在其他上下文中是隐藏的。

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

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

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

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