unit-testing - 基本上执行持久性的单元测试代码 - 我应该打扰吗？

Question

我正在使用与数据库交互的 api。这个 api 具有查询、加载和保存元素到数据库的方法。我已经编写了集成测试来执行诸如创建新实例之类的操作，然后检查当我对该实例进行查询时是否找到了正确的实例。这一切都很好。

我想为这段代码更快地运行单元测试，但我想知道任何单元测试的用处，以及它们是否真的给了我任何东西。例如，假设我有一个类来保存我通过 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

看看测试是什么样的。如果您只测试输入的内容是否最终出现在数据库等中。您可能只通过自动集成测试来做正确的事情。如果有您想要测试的逻辑，那么您可能想看看是否可以将您的逻辑分解为可以进行单元测试的单独类和不包含逻辑的基础结构代码的外观。