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

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

我使用PrivateObject类。但如前所述，最好避免测试私有方法。

Class target = new Class();
PrivateObject obj = new PrivateObject(target);
var retVal = obj.Invoke("PrivateMethod");
Assert.AreEqual(retVal);

在CodeProject上，有一篇文章简要讨论了测试私有方法的优缺点。然后它提供一些反射代码来访问私有方法(类似于Marcus上面提供的代码)。我在这个示例中发现的唯一问题是代码没有考虑重载方法。

你可以在这里找到文章:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

一种方法是保护您的方法，并编写一个继承要测试的类的测试fixture。这样，您既没有将方法公开，但是启用了测试。

这里有一个例子，首先是方法签名:

private string[] SplitInternal()
{
    return Regex.Matches(Format, @"([^/\[\]]|\[[^]]*\])+")
                        .Cast<Match>()
                        .Select(m => m.Value)
                        .Where(s => !string.IsNullOrEmpty(s))
                        .ToArray();
}

下面是测试:

/// <summary>
///A test for SplitInternal
///</summary>
[TestMethod()]
[DeploymentItem("Git XmlLib vs2008.dll")]
public void SplitInternalTest()
{
    string path = "pair[path/to/@Key={0}]/Items/Item[Name={1}]/Date";
    object[] values = new object[] { 2, "Martin" };
    XPathString xp = new XPathString(path, values);

    PrivateObject param0 = new PrivateObject(xp);
    XPathString_Accessor target = new XPathString_Accessor(param0);
    string[] expected = new string[] {
        "pair[path/to/@Key={0}]",
        "Items",
        "Item[Name={1}]",
        "Date"
    };
    string[] actual;
    actual = target.SplitInternal();
    CollectionAssert.AreEqual(expected, actual);
}

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

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