单元测试和检查私有变量值

Question

我正在使用 C#、NUnit 和 Rhino Mocks 编写单元测试。 以下是我正在测试的课程的相关部分：

public class ClassToBeTested
{
    private IList<object> insertItems = new List<object>();

    public bool OnSave(object entity, object id)
    {
        var auditable = entity as IAuditable;
        if (auditable != null) insertItems.Add(entity);

        return false;            
    }
}

我想在调用 OnSave 后测试 insertItems 中的值：

[Test]
public void OnSave_Adds_Object_To_InsertItems_Array()
{
     Setup();

     myClassToBeTested.OnSave(auditableObject, null);

     // Check auditableObject has been added to insertItems array            
}

这方面的最佳做法是什么？我考虑过将 insertItems 添加为具有公共 get 的属性，或者将 List 注入 ClassToBeTested，但不确定我是否应该修改代码以进行测试。

我已经阅读了很多关于测试私有方法和重构的帖子，但这是一个如此简单的类，我想知道最好的选择是什么。

Answer 1

快速回答是，您永远不应该从您的单元测试中访问非公共成员。它完全违背了拥有测试套件的目的，因为它将您锁定在您可能不想保持这种方式的内部实现细节中。

更长的答案与接下来要做什么有关？在这种情况下，重要的是要了解实现的原因（这就是 TDD 如此强大的原因，因为我们使用测试来指定预期的行为，但我感觉你没有使用 TDD）。

在您的情况下，首先想到的问题是：“为什么将 IAuditable 对象添加到内部列表中？”或者，换一种说法，“这个实现的预期外部可见结果是什么？”根据这些问题的答案，这就是您需要测试的内容。

如果您将 IAuditable 对象添加到您的内部列表，因为您以后想将它们写入审计日志（只是一个疯狂的猜测），然后调用写入日志的方法并验证是否写入了预期的数据。

如果您将 IAuditable 对象添加到您的内部列表中，因为您想收集针对某种后来约束的证据，那么请尝试对其进行测试。

如果您添加代码的原因不明，请再次删除它:)

重要的是测试行为而不是实现是非常有益的。它也是一种更健壮和可维护的测试形式。

不要害怕修改您的被测系统 (SUT) 以提高可测试性。只要您的添加在您的领域中有意义并遵循面向对象的最佳实践，就没有问题 - you would just be following the Open/Closed Principle。

Answer 2

您不应该检查添加项目的列表。如果您这样做，您将为列表中的 Add 方法编写单元测试，而不是为 您的 代码编写测试。只需检查 OnSave 的返回值；这就是你想要测试的全部内容。

如果您真的关心 Add，请将其从等式中模拟出来。

编辑：

@TonE：在阅读了您的 cmets 之后，我想说您可能想要更改当前的 OnSave 方法以让您了解失败。如果转换失败等，您可以选择抛出异常。然后您可以编写一个预期和异常的单元测试，而另一个则没有。

Answer 3

我会说“最佳实践”是用不同的对象测试一些有意义的东西，因为它将实体存储在列表中。

换句话说，存储类后，类的行为有何不同，并测试该行为。存储是一个实现细节。

话虽如此，但并非总是可以做到这一点。

如果需要，您可以使用reflection。

Answer 4

如果我没记错的话，您真正想要测试的是，它仅在可以将项目转换为 IAuditable 时才将项目添加到列表中。因此，您可能会使用方法名称编写一些测试，例如：

• NotIAuditableIsNotSaved
• IAuditableInstanceIsSaved
• IAuditableSubclassInstanceIsSaved

...等等。

问题是，正如您所注意到的，鉴于您的问题中的代码，您只能通过间接方式执行此操作 - 只能通过检查私有 insertItems IList<object> 成员（通过反射或添加属性仅用于测试) 或将列表注入到类中：

public class ClassToBeTested
{
    private IList _InsertItems = null;

    public ClassToBeTested(IList insertItems) {
      _InsertItems = insertItems;
    }
}

那么，测试就很简单了：

[Test]
public void OnSave_Adds_Object_To_InsertItems_Array()
{
     Setup();

     List<object> testList = new List<object>();
     myClassToBeTested     = new MyClassToBeTested(testList);

     // ... create audiableObject here, etc.
     myClassToBeTested.OnSave(auditableObject, null);

     // Check auditableObject has been added to testList
}

注入是最具前瞻性和不引人注目的解决方案，除非您有理由认为该列表将成为您的公共界面的一个有价值的部分（在这种情况下，添加一个属性可能会更好 - 当然，属性注入也是完全合法的)。你甚至可以保留一个提供默认实现（new List()）的无参数构造函数。

这确实是一个好习惯；考虑到它是一个简单的类，它可能会让您觉得有点过度设计，但仅可测试性就值得了。然后最重要的是，如果你找到了另一个你想使用该类的地方，那将是锦上添花，因为你不会被限制在使用 IList （并不是说稍后进行更改会花费很多精力)。

Answer 5

如果列表是内部实现细节（而且看起来确实如此），那么您不应该对其进行测试。

一个很好的问题是，如果将项目添加到列表中，预期的行为是什么？这可能需要另一种方法来触发它。

    public void TestMyClass()
    {
        MyClass c = new MyClass();
        MyOtherClass other = new MyOtherClass();
        c.Save(other);

        var result = c.Retrieve();
        Assert.IsTrue(result.Contains(other));
    }

在这种情况下，我断言正确的、外部可见的行为是，在保存对象后，它将被包含在检索到的集合中。

如果结果是，在将来，传入的对象应该在某些情况下对其进行调用，那么您可能会有这样的事情（请原谅伪 API）：

    public void TestMyClass()
    {
        MyClass c = new MyClass();
        IThing other = GetMock();
        c.Save(other);

        c.DoSomething();
        other.AssertWasCalled(o => o.SomeMethod());
    }

在这两种情况下，您都在测试类的外部可见行为，而不是内部实现。

Answer 6

您需要的测试数量取决于代码的复杂性——大概有多少决策点。不同的算法可以实现相同的结果，但其实现的复杂度不同。您如何编写一个独立于实现的测试，并且仍然确保您有足够的决策点覆盖率？

现在，如果您正在设计更大的测试，比如说集成级别，那么，不，您不想编写实现或测试私有方法，但问题是针对小的单元测试范围。