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

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的Property添加,或者将List注入ClassToBeTested,但不确定我是否应该修改代码以进行测试.

我已经阅读了许多关于测试私有方法和重构的帖子,但这是一个非常简单的类,我想知道什么是最好的选择.

Answer 1

快速回答是,您永远不应该从单元测试中访问非公开成员.它完全违背了拥有测试套件的目的,因为它会将您锁定在内部实现细节中,您可能不希望这样做.

更长的答案与当时的做法有关？在这种情况下,重要的是要理解为什么实现是这样的(这就是为什么TDD如此强大,因为我们使用测试来指定预期的行为,但我感觉你没有使用TDD).

在您的情况下,首先想到的问题是:"为什么将IAuditable对象添加到内部列表？" 或者换句话说," 这种实施的预期外部可见结果是什么？" 根据这些问题的答案,这就是您需要测试的内容.

如果您将IAuditable对象添加到内部列表中,因为您以后想要将它们写入审计日志(只是一个疯狂的猜测),那么调用写入日志的方法并验证是否写入了预期的数据.

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

如果您为无可测量的原因添加了代码,则再次将其删除:)

重要的是,测试行为而不是实现是非常有益的.它也是一种更强大和可维护的测试形式.

不要害怕修改您的被测系统(SUT)以使其更易于测试.只要您的添加内容在您的域中有意义并遵循面向对象的最佳实践,就没有问题 - 您只需遵循开放/封闭原则即可.

Answer 2

您不应该检查添加项目的列表.如果你这样做,你会写一个单元测试的名单上的Add方法,而不是一个测试你的代码.只需检查OnSave的返回值; 这真的是你想测试的全部.

如果你真的关心Add,那就把它嘲弄出来.

编辑:

@TonE:阅读完你的评论之后我会说你可能想要改变你当前的OnSave方法,让你知道失败.如果转换失败等,您可以选择抛出异常.然后,您可以编写期望和异常的单元测试,而不是.