对于任何想要运行私有方法的人来说。这适用于任何单元测试框架，只使用旧的Reflection。

public class ReflectionTools
{
    // If the class is non-static
    public static Object InvokePrivate(Object objectUnderTest, string method, params object[] args)
    {
        Type t = objectUnderTest.GetType();
        return t.InvokeMember(method,
            BindingFlags.InvokeMethod |
            BindingFlags.NonPublic |
            BindingFlags.Instance |
            BindingFlags.Static,
            null,
            objectUnderTest,
            args);
    }
    // if the class is static
    public static Object InvokePrivate(Type typeOfObjectUnderTest, string method, params object[] args)
    {
        MemberInfo[] members = typeOfObjectUnderTest.GetMembers(BindingFlags.NonPublic | BindingFlags.Static);
        foreach(var member in members)
        {
            if (member.Name == method)
            {
                return typeOfObjectUnderTest.InvokeMember(method, BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.InvokeMethod, null, typeOfObjectUnderTest, args);
            }
        }
        return null;
    }
}

然后在你的实际测试中，你可以这样做:

Assert.AreEqual( 
  ReflectionTools.InvokePrivate(
    typeof(StaticClassOfMethod), 
    "PrivateMethod"), 
  "Expected Result");

Assert.AreEqual( 
  ReflectionTools.InvokePrivate(
    new ClassOfMethod(), 
    "PrivateMethod"), 
  "Expected Result");

我认为应该问的一个更基本的问题是，为什么要首先测试私有方法。这是一种代码气味，你试图通过类的公共接口测试私有方法，而该方法是私有的，因为它是一个实现细节。人们应该只关心公共接口的行为，而不是它在背后是如何实现的。

如果我想测试私有方法的行为，通过使用公共重构，我可以将其代码提取到另一个类中(可能具有包级可见性，以确保它不是公共API的一部分)。然后我可以单独测试它的行为。

重构的产物意味着私有方法现在是一个独立的类，它已经成为原始类的合作者。通过它自己的单元测试，它的行为将被很好地理解。

然后，当我试图测试原始类时，我可以模拟它的行为，这样我就可以集中精力测试该类公共接口的行为，而不必测试公共接口的组合爆炸及其所有私有方法的行为。

我认为这类似于开车。当我开车时，我不会把引擎盖打开，这样我就能看到发动机在工作。我依靠汽车提供的接口，即转速计数器和速度计来知道发动机是否在工作。我依靠的是当我踩下油门踏板时，汽车实际上在移动。如果我想测试引擎，我可以单独检查它。: D

当然，如果您有遗留应用程序，直接测试私有方法可能是最后的手段，但我更希望对遗留代码进行重构，以实现更好的测试。迈克尔·费瑟就这个主题写了一本很棒的书。http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

在我看来，你应该只对类的公共API进行单元测试。

为了对方法进行单元测试，将其设为公共，会破坏封装，暴露实现细节。

一个好的公共API解决了客户端代码的直接目标，并且完全解决了这个目标。

由于某些原因，私有类型、内部变量和私有成员是这样的，通常你不想直接打乱它们。如果您这样做了，很可能稍后会崩溃，因为不能保证创建这些程序集的人会保留私有/内部实现。

但是，有时，在对编译或第三方程序集进行一些hack /探索时，我自己最终想要初始化一个私有类或具有私有或内部构造函数的类。或者，有时，在处理无法更改的预编译遗留库时——我最终会针对私有方法编写一些测试。

因此诞生了AccessPrivateWrapper - http://amazedsaint.blogspot.com/2010/05/accessprivatewrapper-c-40-dynamic.html -它是一个快速的包装类，使用c# 4.0的动态特性和反射可以使工作变得容易。

您可以创建内部/私有类型，例如

    //Note that the wrapper is dynamic
    dynamic wrapper = AccessPrivateWrapper.FromType
        (typeof(SomeKnownClass).Assembly,"ClassWithPrivateConstructor");

    //Access the private members
    wrapper.PrivateMethodInPrivateClass();

JAVA语言

在这里，您可以使用模拟行为覆盖测试类的特定方法。

对于下面的代码:

public class ClassToTest 
{
    public void methodToTest()
    {
        Integer integerInstance = new Integer(0);
        boolean returnValue= methodToMock(integerInstance);
        if(returnValue)
        {
            System.out.println("methodToMock returned true");
        }
        else
        {
            System.out.println("methodToMock returned true");
        }
        System.out.println();
    }
    private boolean methodToMock(int value)
    {
        return true;
    }
}

测试类将是:

public class ClassToTestTest{

    @Test
    public void testMethodToTest(){

        new Mockup<ClassToTest>(){
            @Mock
            private boolean methodToMock(int value){
                return true;
            }
        };

        ....    

    }
}

我倾向于不使用编译器指令，因为它们很快就会把事情弄得乱七八糟。如果你真的需要它们，一种缓解它的方法是把它们放在一个partial类中，并让你的构建在制作产品版本时忽略那个.cs文件。