在c#中，您可以使用我下面提供的代码。尽管我认为只有在绝对需要的时候才应该进行私有方法的单元测试。我遇到过一些我觉得有必要这样做的案例。下面是我在UnitTestBase类中创建的一些c#方法，我继承了我的UnitTest类(你也可以把它放在一个静态的“助手”类中)。HTH

protected internal static TResult? InvokePrivateInstanceMethod<TType, TResult>(string methodName, object?[]? methodArguments = null, params object?[]? constructorArguments)
{
    var classType = typeof(TType);
    var instance = Activator.CreateInstance(classType, constructorArguments);
    var privateMethodInfo = classType.GetMethods(BindingFlags.NonPublic | BindingFlags.Instance)
                                        .FirstOrDefault(m => m.IsPrivate &&
                                            m.Name.Equals(methodName, StringComparison.Ordinal) &&
                                            m.ReturnType.Equals(typeof(TResult)));
 
    if (privateMethodInfo is null)
    {
        throw new MissingMethodException(classType.FullName, methodName);
    }

    var methodResult = privateMethodInfo.Invoke(instance, methodArguments);
    if (methodResult is not null)
    {
        return (TResult)methodResult;
    }

    return default;
}

protected internal static async Task<TResult?> InvokePrivateInstanceMethodAsync<TType, TResult>(string methodName, object?[]? methodArguments = null, params object?[]? constructorArguments)
{
    var classType = typeof(TType);
    var instance = Activator.CreateInstance(classType, constructorArguments);
    var privateMethodInfo = classType.GetMethods(BindingFlags.NonPublic | BindingFlags.Instance)
                                        .FirstOrDefault(m => m.IsPrivate &&
                                            m.Name.Equals(methodName, StringComparison.Ordinal) &&
                                            m.ReturnType.Equals(typeof(Task<TResult>)));
            
    if (privateMethodInfo is null)
    {
        throw new MissingMethodException(classType.FullName, methodName);
    }

    var methodResult = privateMethodInfo.Invoke(instance, methodArguments);
    if (methodResult is not null)
    {
        return await (Task<TResult>)methodResult;
    }

    return default;
}

如果您想对私有方法进行单元测试，那么可能会出现一些错误。单元测试(一般来说)用于测试类的接口，即类的公共(和受保护)方法。你当然可以“破解”一个解决方案(即使只是通过公开方法)，但你可能还想考虑:

如果您想测试的方法确实值得测试，那么将它移到自己的类中可能是值得的。 向调用私有方法的公共方法添加更多测试，测试私有方法的功能。(正如评论者所指出的，只有当这些私有方法的功能确实是公共接口的一部分时，才应该这样做。如果它们实际上执行对用户隐藏的功能(即单元测试)，这可能是不好的)。

您可以在Visual studio 2008中为私有方法生成测试方法。当您为私有方法创建单元测试时，test References文件夹将添加到测试项目中，访问器将添加到该文件夹中。存取器也在单元测试方法的逻辑中被引用。这个访问器允许单元测试调用正在测试的代码中的私有方法。 详情请看

http://msdn.microsoft.com/en-us/library/bb385974.aspx

我还使用了InternalsVisibleToAttribute方法。值得一提的是，如果你为了达到这个目的而将你之前的私有方法变成内部方法，那么也许它们不应该成为直接单元测试的对象。

毕竟，您是在测试类的行为，而不是它的具体实现——您可以在不更改前者的情况下更改后者，并且您的测试仍然应该通过。

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

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

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

测试私有方法可能没有用处。然而，我有时也喜欢从测试方法调用私有方法。大多数时候为了防止代码重复用于测试数据生成…

微软为此提供了两种机制:

访问器

转到类定义的源代码 右键单击类名 选择“创建私有访问器” 选择要在其中创建访问器的项目 你将得到一个名为foo_accessor的新类。 该类将在编译期间动态生成，并提供所有公共成员。

然而，当涉及到原始类的接口更改时，该机制有时有点棘手。所以，大多数时候我避免使用这个。

PrivateObject类 另一种方法是使用microsoft。visualstudio。testtools。unittest。privateobject

// Wrap an already existing instance
PrivateObject accessor = new PrivateObject( objectInstanceToBeWrapped );

// Retrieve a private field
MyReturnType accessiblePrivateField = (MyReturnType) accessor.GetField( "privateFieldName" );

// Call a private method
accessor.Invoke( "PrivateMethodName", new Object[] {/* ... */} );