当我的类中有足够复杂的私有方法，以至于我觉得需要直接测试私有方法时，这是一种代码气味：我的类太复杂了。

我解决这些问题的通常方法是梳理出一个包含有趣内容的新类。通常，这个方法及其交互的字段，或者可以将另一个或两个方法提取到一个新类中。

新类将这些方法公开为“public”，因此可以对它们进行单元测试。新的和旧的类现在都比原来的类简单，这对我来说很好（我需要保持简单，否则我会迷路！）。

注意，我并不是建议人们不用大脑就可以创建课程！这里的重点是使用单元测试的力量来帮助您找到好的新类。

正如上面许多人所建议的，一个好的方法是通过公共接口测试它们。

如果您这样做，最好使用代码覆盖工具（如EMMA）来查看您的私有方法是否确实在测试中执行。

从本文：使用JUnit和SuiteRunner测试私有方法（Bill Venners）中，您基本上有4个选项：

不要测试私有方法。授予方法包访问权限。使用嵌套测试类。使用反射。

在C++中：在包含包含要测试的私有函数的类头之前。

使用此代码：

#define private public
#define protected public

如果你担心没有像很多帖子所建议的那样测试私有方法，那么考虑一下代码覆盖工具将准确地确定你的代码被测试了多少以及泄漏的地方，所以这样做是可以接受的。

将问题作者引向“变通方法”的答案对社区造成了巨大的伤害。测试是所有工程学科的主要组成部分。你不会想买一辆没有经过适当测试的汽车，而且测试的方式很有意义，那么为什么有人会想购买或使用测试不好的软件呢？人们这样做的原因可能是因为测试不好的软件的影响是事后才感受到的，我们通常不会把它们与身体伤害联系起来。

这是一种非常危险的观念，很难改变，但我们有责任提供安全的产品，而不管管理层如何欺负我们。想想Equifax黑客。。。

我们必须努力营造一个鼓励良好软件工程实践的环境。这并不意味着排斥我们中那些不认真对待自己手艺的弱者/懒惰者，而是创造一种责任感和自我反思的现状，鼓励每个人在精神和技能上追求成长。

我仍在学习，可能自己也有错误的看法/观点，但我坚信，我们需要对良好做法负责，避免不负责任的黑客或解决问题的方法。

测试私有方法会破坏类的封装，因为每次更改内部实现时都会破坏客户端代码（在本例中是测试）。

所以不要测试私有方法。