单元测试和对象的范围 - 如何测试私有/内部方法等？

Question

假设我有一个类库项目。我在该库中有一个类，该类有一些仅在类内部使用的方法。像这样：

public class MyClass
{
  public void MyPublicMethod
  {
    int k

    // do something ...

    int z = MyInternalMethod(k);
    // do something else ...

  }

  internal int MyInternalMethod(int i)
  {
        // do something ...

  }
}

现在我想为这些方法编写单元测试。我将创建一个“单元测试”项目，从中引用 nunit 并编写类似的内容

[TestFixture]
public class UnitTests
{
  private MyClass myClass;

  [SetUp]
  public void SetupTest
  {
    myClass = new MyClass();
  }

  [Test]
  public void TestMyInternalMethod
  {
    int z = 100;
    int k = myClass.MyInternalMethod(z); //CAN NOT DO THIS!
    Assert.AreEqual(k, 100000);
  }

  [TearDown]
  public void TearDown
  {
    myClass = null;
  }
}

当然，由于 MyInternalMethod 范围，我不能这样做。处理这种情况的正确方法是什么？

Answer 1

我猜这取决于您对单位是什么的看法，对吗？我通常为可访问的接口编写单元测试并忽略私有的东西。我曾与一些人合作，他们将私有内容保护（java）以进行单元测试访问。我真的不喜欢这种方法，因为它牺牲了测试访问的类设计的简洁性。

Answer 2

您可以使用 InternalsVisibleToAttribute 使内部结构对某些程序集可见。

Answer 3

我只是测试公共方法（不，我不关心覆盖率指标，我关心有效的功能）。

请注意，如果公共方法不使用内部方法，则内部方法不需要存在！

Answer 4

这是关于该主题的一篇好文章：

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

我个人只是避免编写任何执行真正复杂操作的私有方法。还有其他方法可以封装您不想公开的行为，同时仍然让您自己能够测试应该隐藏的内容。我认为完美封装和可测试性之间需要权衡。完美的封装很难实现，让自己对类有更多的了解通常会更有益。这可能是有争议的。

Answer 5

很多人会说你不应该测试内部方法，而应该通过公共API来测试它们。无论如何，如果您确实想访问这些私有成员，则可以使用反射。

Answer 6

有两种情况：要么从某个公共方法调用您的私有方法，在这种情况下您可以通过该方法测试它们。或者，它们不会从某些公共方法中调用，在这些方法中它们根本无法被调用，是死代码，应该被删除，而不是测试。

请注意，如果您正在进行 TDD，私有方法只能通过从公共方法中提取它们而出现，在这种情况下它们已经被自动测试。

Answer 7

Visual Studio 可以为您生成私有访问器。查看 MSDN 上的私有、内部和友元方法的单元测试 。我相信 VS2005 只是生成私有访问器类并将其添加到您的单元测试项目中。所以当事情发生变化时你必须重新生成它们。然而，VS2008 生成一个私有访问器程序集并使其可供单元测试项目使用。你正在使用 NUnit，但我认为应该没问题。一探究竟。这样您就可以使您的实际代码免受任何与测试相关的代码和/或黑客攻击。

Answer 8

过去，我在与被测类相同的命名空间和程序集中创建了测试装置来测试内部方法。我并不是说是否应该测试内部方法。实际上，您可以先测试它们，然后再进行重构。

我还创建了部分类来测试私有方法，并在整个部分（位于其自己的文件中）周围使用了编译器指令。再说一次，并不是说这是最好的，但有时你需要前进。

在构建时，我们可以在“调试”或“发布”模式下运行单元测试，并且如果需要，我们可以从任一构建中删除测试代码，因此将测试代码与被测代码放在一起没有什么害处;如果有的话，它的参数类似于 code-and-data-together = object 或 object-and-doc-comments = Documented-object。换句话说：代码、数据、测试和文档注释在一起 = 内聚单元。

构建过程中的额外时间可以忽略不计。

Answer 9

我使用了几种方法来做到这一点。我已经将我的私有方法设置为受保护，这样我就可以从单元测试中的类继承并创建一个“帮助器”类来测试这些方法。另一个是反思。在我看来，反射是更容易的，但确实违背了你的类应该如何设计用于测试。这是我正在谈论的内容的简化版本。

public static class ReflectionHelper
{
    public static object RunStaticMethod<TInstance>(string methodName, params object[] methodParams)
    {
        var methodType = BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic;
        return RunMethod<TInstance>(null, methodName, methodType, methodParams);
    }

    public static object RunInstanceMethod<TInstance>(this TInstance instance, string methodName, params object[] methodParams)
    {
        var methodType = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
        return RunMethod<TInstance>(instance, methodName, methodType, methodParams);
    }

    private static object RunMethod<TInstance>(object instance, string methodName, BindingFlags methodType, params object[] methodParams)
    {
        var instanceType = typeof(TInstance);
        var method = instanceType.GetMethod(methodName, methodType);
        if (method == null)
        {
            throw new ArgumentException(string.Format("There is no method '{0}' for type '{1}'.", methodName, instanceType));
        }

        var result = method.Invoke(instance, methodParams);

        return result;
    }
}

给定一个这样的类，

public class User
{
    public string FirstName { get; set; }
    public string LastName { get; set; }

    internal string GetPrettyName()
    {
        return string.Concat(FirstName, " ", LastName);
    }

    static internal int GetSystemId(string userName)
    {
        // some magic here
        return 13;
    }
}

你会这样使用它们

var user = new User { FirstName = "Peter", LastName = "Gibbons" };

var name = user.RunInstanceMethod("GetPrettyName");
Assert.That(name, Is.EqualTo("Peter Gibbons"));

var id = ReflectionHelper.RunStaticMethod<User>("GetSystemId", "tester");
Assert.That(id, Is.EqualTo(13));

Answer 10

我喜欢将我的单元测试与他们正在测试的单元测试放在同一类中。这有两个优点，第一是它解决了您遇到的问题，第二是您永远不会丢失或忘记它们，因为如果它们位于单独的程序集中，通常会出现这种情况。

并非每个人都同意这种方法（请参阅此问题< /a> 我之前问过）但到目前为止我还没有发现它或有任何缺陷向我指出。我已经用这种方式进行单元测试四五年了。

#if UNITTEST
using NUnit.Framework;
#endif

public class MyBlackMagic
{
    private int DoMagic()
    {
        return 1;
    }

    #if UNITTEST

    [TestFixture]
    public class MyBlackMagicUnitTest
    {
         [TestFixtureSetUp]
         public void Init()
         {
             log4net.Config.BasicConfigurator.Configure();
         }

         [Test]
         public void DoMagicTest()
         {
             Console.WriteLine(System.Reflection.MethodBase.GetCurrentMethod().Name);
             Assert.IsTrue(DoMagic() == 1, "You are not a real magician!");
         }
     }

     #endif
 }