我正在尝试使用许多私有方法对一个类进行单元测试。每个私有方法都可以相当广泛。
我可以使方法包作用域（这会导致警告），或者我可以使用下面的代码来测试它：
Method method = instance.getClass().getDeclaredMethod("methodName");
method.setAccessible(true);
Object object = method.invoke(instance);
assertNotNull(object);
该类不是“上帝对象”，它的大多数方法都涉及它的所有领域。
关于如何更好地处理这个问题的任何建议？
测试私有方法也可能是一种测试气味。
我的参考是优秀的书http://www.manning.com/rainsberger/
您应该测试行为而不是方法：粒度有点不同。
示例1：要测试一个Pile，你如何测试
push并且pop不相互引用？但是测试全局行为是可能的。这提醒我们，即使对于测试，对象也是正确的粒度，而不是方法。示例2：当你想测试几个对象之间的交互时，一个方法一个方法的测试显然是不正确的，你想测试一个全局行为。
如果一个方法不是公共的，它就不能被外界调用，它的行为也没有那么严格的定义。但最重要的是，如果您测试私有方法，您以后将无法重构代码。所以测试应该只在公共代码上进行。
KLE 是对的。
但是，如果您正在使用遗留代码并且您必须处理私有方法中的依赖关系，那么最后一个选择是JMockit。我没有使用过它，但在The Art of Unit Testing中阅读了它。它应该能够将呼叫从原始课程交换到您的假课程。
使用它来打破对其他对象的依赖关系，以便您可以测试公共方法，而不是测试私有方法。并将其用作重构为解耦设计的安全网。
如果您还没有使用它，这可能是一个延伸......但是 Groovy 非常适合违反单元测试的访问限制......您可以直接进入并调用这些方法，就好像它们是公开的，而无需额外的反射。
我很好奇当你打包作用域方法时你会得到什么样的警告，但无论如何，解决这类问题的一种方法是让测试成为对象的静态内部类。这可能需要权衡；如果部署大小是一个重要问题，您可能需要将类排除在与代码一起打包的范围之外，并且您需要小心不要将测试框架中的依赖项意外地引入生产代码中。
另一个可能的选择是拥有一个静态内部类来帮助公开您需要的方法，并且测试将使用它作为私有方法的传递。这里的缺点是这个类本质上向任何想要使用该类的人公开了私有方法，所以你必须小心清楚地表明这个类仅用于测试目的。
您可以考虑使用反射。