正如上面引用的，“如果你不测试你的私有方法，你怎么知道它们不会崩溃?”

这是一个大问题。单元测试的一个重要要点是尽快知道在哪里、何时以及如何发生故障。这样就减少了大量的开发和QA工作。如果所有测试的都是公开的，那么您就没有对类的内部进行诚实的覆盖和描述。

我发现最好的方法之一是将测试引用添加到项目中，并将测试放在与私有方法并行的类中。放入适当的构建逻辑，这样测试就不会构建到最终项目中。

然后，您就有了测试这些方法的所有好处，您可以在几秒钟内而不是几分钟或几小时内发现问题。

总之，单元测试你的私有方法。

你不应该这么做。如果您的私有方法有足够的复杂性，必须进行测试，您应该将它们放在另一个类中。保持高内聚性，类应该只有一个目的。类公共接口应该足够了。

其中一个要点是

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

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

相反

另一方面，在原始类之外调用私有方法是一个主要问题。在一些模拟工具中，模拟私有方法也有局限性。(例: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

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

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

当我在我们的项目中越来越多地遵循我们最新的QA建议时，我感觉有必要测试私有函数:

每个函数圈复杂度不超过10。

现在，执行这项政策的副作用是，我的许多非常大的公共职能被划分为许多更集中的，更好地命名为私人职能。 公共功能仍然存在(当然)但本质上被简化为所有那些私人的“子功能”

这实际上很酷，因为调用堆栈现在更容易阅读(而不是一个大函数中的bug，我在一个子子函数中有一个bug，它具有调用堆栈中先前函数的名称，以帮助我理解“我是如何到达那里的”)

然而，现在似乎更容易直接对那些私有函数进行单元测试，而将大型公共函数的测试留给某种需要解决场景的“集成”测试。

这只是我的个人意见。

测试的目的是什么?

到目前为止，大多数答案都说私有方法是实现细节，只要公共接口经过良好测试并能够正常工作，这些实现细节就不重要(至少不应该)。如果测试的唯一目的是保证公共接口正常工作，那么这是绝对正确的。

就我个人而言，我对代码测试的主要用途是确保将来的代码更改不会导致问题，并且在出现问题时帮助我进行调试。我发现对私有方法的测试就像对公共接口的测试一样彻底(如果不是更彻底的话!)，可以进一步达到这个目的。

考虑:您有一个公共方法A，它调用私有方法B。A和B都使用方法C。C被更改(可能由您更改，也可能由供应商更改)，导致A开始测试失败。对B进行测试不是很有用吗，即使它是私有的，这样你就知道问题是在A使用C, B使用C，还是两者都有?

Testing private methods also adds value in cases where test coverage of the public interface is incomplete. While this is a situation we generally want to avoid, the efficiency unit testing depends both on the tests finding bugs and the associated development and maintenance costs of those tests. In some cases, the benefits of 100% test coverage may be judged insufficient to warrant the costs of those tests, producing gaps in the public interface's test coverage. In such cases, a well-targeted test of a private method can be a very effective addition to the code base.