对于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!
}

在您的课堂上：

namespace my_namespace {
    #ifdef UNIT_TEST
        class test_class;
    #endif

    class my_class {
        public:
            #ifdef UNIT_TEST
                friend class test_class;
            #endif
        private:
            void fun() { cout << "I am private" << endl; }
    }
}

在单元测试类中：

#ifndef UNIT_TEST
    #define UNIT_TEST
#endif

#include "my_class.h"

class my_namespace::test_class {
    public:
        void fun() { my_obj.fun(); }
    private:
        my_class my_obj;
}

void my_unit_test() {
    test_class test_obj;
    test_obj.fun(); // here you accessed the private function ;)
}

我想测试私有方法的两个例子：

解密例程-我不会想让任何人都能看到它们为了测试，否则任何人都可以使用它们来解密。但他们是代码固有的、复杂的，并且需要始终工作（明显的例外是反射，在大多数情况下，当SecurityManager未配置为防止这种情况发生时，反射甚至可以用于查看私有方法）。为社区创建SDK消耗在这里，公众对完全不同的含义，因为是全世界都能看到的代码（不仅仅是我的应用程序内部）。我把如果我不这样做，请将代码转换为私有方法希望SDK用户看到它-我不要将其视为代码气味SDK编程是如何工作的。但是当然我还需要测试私有方法，它们在哪里我的SDK的功能生活。

我理解只测试“合同”的想法。但我看不出有人可以主张不测试代码，因为您的里程可能会有所不同。

因此，我的权衡涉及到用反射使JUnit测试复杂化，而不是损害我的安全性和SDK。

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

使用此代码：

#define private public
#define protected public

PowerMock.Whitebox是我见过的最好的选项，但当我阅读它的源代码时，它会读取带有反射的私有字段，所以我想我有了答案：

使用PowerMock测试私有内部状态（字段），或仅进行反射，而无需引入其他独立性的开销对于私人方法：事实上，这个问题本身的赞成票，以及大量的评论和答案，表明这是一个非常并发和有争议的话题，无法给出适合每种情况的确切答案。我知道只有合同需要测试，但我们也需要考虑保险范围。事实上，我怀疑只有测试合约才能100%让一个类免于错误。私有方法是那些在定义数据的类中处理数据的方法，因此对其他类不感兴趣，因此我们不能简单地公开以使其可测试。我会尽量不去测试它们，但当你必须的时候，就去尝试，忘记这里的所有答案。你比互联网上的任何人都更了解自己的处境和限制。当您可以控制代码时，请使用它。经过考虑，但不要过度思考。

一段时间后，当我重新考虑时，我仍然相信这是真的，但我看到了更好的方法。

首先，Powermock.Whitebox仍然可用。

而且，Mockito Whitebox在v2之后被隐藏了（我可以在Whitebox中找到的最新版本是testImplementation“org.Mockito:Mockito core:1.10.19”），并且它一直是org.mockit.internal包的一部分，未来很可能会发生重大变化（请参阅本文）。所以现在我倾向于不使用它。

在Gradle/MMaven项目中，如果您定义了私有方法或字段，那么除了反射之外，没有任何其他方法可以访问它们，因此第一部分是正确的。但是，如果您将可见性更改为“包私有”，则测试包中遵循相同结构的测试将可以访问它们。这也是我们被鼓励在主包和测试包中创建相同层次结构的另一个重要原因。因此，当您可以控制生产代码和测试时，删除私有访问修饰符可能是您的最佳选择，因为相对而言，它不会造成巨大影响。这使得测试和私人方法间谍成为可能。

@Autowired
private SomeService service; // With a package private method "doSomething()"

@Test
void shouldReturnTrueDoSomething() {
    assertThat(doSomething(input), is(true)); // Package private method testing
}

@Test
void shouldReturnTrueWhenServiceThrowsException() {
    SomeService spy = Mockito.spy(service); // Spying real object
    doThrow(new AppException()).when(spy).doSomething(input); // Spy package private method
    ...

}

谈到内部字段，在Spring中有ReflectionUtils.setField（）。

最后，有时我们可以绕过问题本身：如果需要满足覆盖要求，也许可以将这些私有方法移到内部静态类中，并忽略Jacobo中的这个类。我只是找到了一些方法来忽略Jacobo Gradle任务中的内部类。另一个问题。

私有方法由公共方法调用，因此公共方法的输入也应测试这些公共方法调用的私有方法。当公共方法失败时，这可能是私有方法的失败。