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

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

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

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

总而言之:

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

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

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

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

我们通过推断来测试私有方法，我的意思是我们寻找总类测试覆盖率至少为95%，但我们的测试只调用公共方法或内部方法。为了获得覆盖，我们需要根据可能发生的不同场景对公众/内部人员进行多次调用。这使得我们的测试更专注于它们所测试的代码的目的。

特朗皮对你链接的帖子的回答是最好的。

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

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

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

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

它加快了以后的调试。

亚当