Question

我正在使用与db交互的api。这个api具有查询，加载和保存元素到db的方法。我编写了集成测试，用于创建新实例，然后检查当我对该实例进行查询时，找到了正确的实例。这一切都很好。

我想对此代码进行更快的运行单元测试，但我想知道任何单元测试的有用性，以及它们是否真的给了我任何东西。例如，假设我有一个类用于通过API保存我的一些元素。这是伪代码，但是我知道我使用的api是如何工作的。

public class ElementSaver
{
    private ITheApi m_api;

    public bool SaveElement(IElement newElement, IElement linkedElement)
    {
        IntPtr elemPtr = m_api.CreateNewElement()
        if (elemPtr==IntPtr.Zero)
        {
            return false;
        }
        if (m_api.SetElementAttribute(elemPtr,newElement.AttributeName,newElement.AttributeValue)==false)
        {
             return false;
        }
        if (m_api.SaveElement(elemPtr)==false)
        {
             return false;
        }

        IntPtr linkedElemPtr = m_api.GetElementById(linkedElement.Id)
        if (linkedElemPtr==IntPtr.Zero)
        {
            return false; 
        }
        if (m_api.LinkElements(elemPtr,linkedElemPtr)==false)
        {
            return false;
        }
        return true;

    }
}

是否值得编写模拟m_api成员的单元测试？似乎我可以测试，如果任何各种调用失败，返回false，并且如果所有各种调用成功返回true，我可以设置期望使用预期参数调用各种方法，但是这有用吗？如果我要重构这段代码，以便它使用一些稍微不同的api方法，但是实现了相同的结果，这会破坏我的测试，我需要更改它们。这种脆弱似乎并不十分有用。

我是否应该为这样的代码进行单元测试，或者我应该坚持使用我所拥有的集成测试？

Answer 1

看看测试是什么样的。如果你只测试进入的东西最终是否存在于数据库中等等。你可能只做自动集成测试就可以做正确的事。如果你想测试逻辑，那么你可能想看看你是否可以将你的逻辑分解为单独的类，你可以单元测试和围绕不包含逻辑的基础设施代码。

Answer 2

在我的代码中模拟m_api是一个好主意，原因如下（并非所有这些都适用于你的伪代码示例）：

如您所述，您可以验证您的班级是否正确执行错误处理
如果您的类中有更复杂的代码（例如，缓存），您可以在模拟上使用期望来确保类的行为正常。例如，检索两次相同的对象，但确保只调用一次m_api。
您的单元测试可以在不创建适当数据集的情况下测试行为。随着m_api下面的数据模型的变化，这会增加可维护性。

单元测试代码基本上是持久性 - 我应该打扰吗？

2 个答案: