我最近遇到了这个问题，并编写了一个名为Picklock的小工具，它避免了显式使用Java反射API的问题，两个示例：

通过Java反射调用方法，例如private void方法（String s）

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

通过Picklock调用方法，例如private void方法（String s）

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

设置字段，例如私有BigInteger金额；-通过Java反射

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

设置字段，例如私有BigInteger金额；-由Picklock提供

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

我认为大多数答案都太粗糙了。这取决于您的代码是否应该测试私有方法。

我过去使用了私人方法测试，我是通过反思来完成的。它对我有用。我意识到它的问题，但对我来说，这是最好的解决方案。

我有一个强大的应用程序，可以模拟100多万人口中的人类行为。每个人都由一个对象表示。该应用程序的主要目的是跟踪某些东西（疾病、信息、思想）如何在人群中传播。

为此，我有方法将疾病或信息从一个对象传递给另一个对象。绝对没有理由公开这些方法，因为最终用户对人与人之间的一次传递不感兴趣。最终用户只对它如何在人群中传播的全貌感兴趣。所以这些方法是私人的。

但我想肯定的是，从一个人向另一个人传递一点信息的行为是否在做它应该做的事情。通过公共用户界面测试它也是不可能的，因为它只是不公开，我认为仅仅为了测试而公开它是很尴尬的。应用程序的最终输出由一直执行的数亿个这样的单个步骤定义。我也不能测试最终输出，因为这涉及到复杂的随机性，这使得它无法预测。

因此，我测试应用程序的方法是测试从一个人向另一个人传递信息的单个步骤。这些都是私人方法。所以我用反思来检验这一点。

我讲这个故事是为了表明这不是一个简单的黑白故事。这取决于您的应用程序。在某些情况下，通过反射测试私有方法可能是最好的选择。

如果这里的一些人在我的用例中知道更好的解决方案，我当然乐意接受纠正。。。。

我最近遇到了这个问题，并编写了一个名为Picklock的小工具，它避免了显式使用Java反射API的问题，两个示例：

通过Java反射调用方法，例如private void方法（String s）

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

通过Picklock调用方法，例如private void方法（String s）

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

设置字段，例如私有BigInteger金额；-通过Java反射

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

设置字段，例如私有BigInteger金额；-由Picklock提供

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

正如其他人所说。。。不要直接测试私有方法。以下是一些想法：

保持所有方法的规模和重点（易于测试，易于发现错误）使用代码覆盖工具。我喜欢Cobertura（哦，快乐的一天，它看起来像是一个新版本！）

在单元测试上运行代码覆盖率。如果您发现方法没有经过充分测试，请添加到测试中以提高覆盖率。目标是100%的代码覆盖率，但要意识到你可能无法做到这一点。

如果您的测试类与应该测试的类在同一个包中呢？

当然，在另一个目录中，源代码使用src&classes，测试类使用test/src和test/classes。让类和测试/类位于类路径中。

对于C++（从C++11开始），将测试类添加为好友非常有效，不会破坏生产封装。

让我们假设我们有一些类Foo和一些真正需要测试的私有函数，还有一些类FooTest应该可以访问Foo的私有成员。然后我们应该写下以下内容：

// prod.h: some production code header

// forward declaration is enough
// we should not include testing headers into production code
class FooTest;

class Foo
{
  // that does not affect Foo's functionality
  // but now we have access to Foo's members from FooTest
  friend FooTest;
public:
  Foo();
private:
  bool veryComplicatedPrivateFuncThatReallyRequiresTesting();
}

// test.cpp: some test
#include <prod.h>

class FooTest
{
public:
  void complicatedFisture() {
    Foo foo;
    ASSERT_TRUE(foo.veryComplicatedPrivateFuncThatReallyRequiresTesting());
  }
}

int main(int /*argc*/, char* argv[])
{
  FooTest test;
  test.complicatedFixture();  // and it really works!
}