如果我发现私有方法非常庞大、复杂或重要到需要自己的测试，我就把它放在另一个类中，并在那里将它设为公共(方法对象)。然后，我可以轻松地测试以前私有但现在是公共的方法，它现在存在于自己的类中。

其中一个要点是

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

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

相反

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

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

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

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

我认为单元测试是用来测试公共方法的。您的公共方法使用您的私有方法，因此它们也间接地接受测试。

如果方法足够重要/复杂，我通常会让它“受保护”并测试它。一些方法将保持私有，并作为公共/受保护方法的单元测试的一部分进行隐式测试。

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

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

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

总而言之:

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

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

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

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

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