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

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

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

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

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

是的，我确实测试私有函数，因为尽管它们是由你的公共方法测试的，但在TDD(测试驱动设计)中测试应用程序的最小部分是很好的。但是在测试单元类中不能访问私有函数。下面是我们测试私有方法的方法。

为什么我们有私有方法?

私有函数主要存在于我们的类中，因为我们希望在公共方法中创建可读的代码。 我们不希望这个类的用户直接调用这些方法，而是通过我们的公共方法。此外，我们不希望在扩展类时改变它们的行为(在受保护的情况下)，因此它是一个private。

当我们编码时，我们使用测试驱动设计(TDD)。这意味着有时我们会偶然发现一个私有的功能片段并想要进行测试。私有函数在phpUnit中是不可测试的，因为我们不能在Test类中访问它们(它们是私有的)。

我们认为有3个解决方案:

1. 你可以通过你的公共方法来测试你的私处

优势

简单的单元测试(不需要“hack”)

缺点

程序员需要了解公共方法，而他只想测试私有方法 您不是在测试应用程序中最小的可测试部分

2. 如果private是如此重要，那么为它创建一个新的单独的类可能是一个代码味道

优势

你可以把它重构成一个新类，因为如果是这样的话 重要的是，其他类可能也需要它 可测试单元现在是一个公共方法，因此可测试

缺点

如果一个类是不需要的，并且只被 方法来自的类 由于增加的开销而造成潜在的性能损失

3.将访问修饰符更改为(final) protected

优势

您正在测试应用程序中最小的可测试部分。当 使用final protected，函数将不会被重写(只是 像一个私人) 无性能损失 没有额外的开销

缺点

你把一个私有访问权限改成了受保护，也就是说 它的孩子可以接触到 您仍然需要在测试类中使用Mock类

例子

class Detective {
  public function investigate() {}
  private function sleepWithSuspect($suspect) {}
}
Altered version:
class Detective {
  public function investigate() {}
  final protected function sleepWithSuspect($suspect) {}
}
In Test class:
class Mock_Detective extends Detective {

  public test_sleepWithSuspect($suspect) 
  {
    //this is now accessible, but still not overridable!
    $this->sleepWithSuspect($suspect);
  }
}

因此，我们的测试单元现在可以调用test_sleepWithSuspect来测试之前的私有函数。

这显然与语言有关。在过去的c++中，我将测试类声明为友类。不幸的是，这需要您的生产代码了解测试类。

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

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

这里有一个例子:

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

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

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

I understand the point of view where private methods are considered as implementations details and then don't have to be tested. And I would stick with this rule if we had to develop outside of the object only. But us, are we some kind of restricted developers who are developing only outside of objects, calling only their public methods? Or are we actually also developing that object? As we are not bound to program outside objects, we will probably have to call those private methods into new public ones we are developing. Wouldn't it be great to know that the private method resist against all odds?

我知道有些人会回答说，如果我们正在开发另一个公共方法到那个对象中，那么这个方法应该被测试，就是这样(私有方法可以在没有测试的情况下继续存在)。但这也适用于一个对象的任何公共方法:当开发一个web应用程序时，一个对象的所有公共方法都是从控制器方法调用的，因此可以认为是控制器的实现细节。

那么为什么我们要单元测试对象呢?因为这是非常困难的，不是说不可能，以确保我们正在测试控制器的方法与适当的输入将触发底层代码的所有分支。换句话说，我们在堆栈中的位置越高，测试所有行为就越困难。私有方法也是如此。

对我来说，私人方法和公共方法之间的界限是测试时的心理标准。对我来说更重要的标准是:

该方法是否在不同的地方被多次调用? 这种方法是否复杂到需要测试?

如果你的私有方法没有通过调用公共方法来测试，那么它在做什么? 我说的是私人的，不是受保护的，也不是朋友。