基本上持久化的單元測試代碼 - 我應該打擾嗎？

我正在使用與數據庫交互的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方法，但是達到了相同的結果，這會破壞我的測試，我需要更改它們。這種脆弱似乎不是很有用。

我是否應該爲像這樣的代碼進行單元測試而煩惱，還是應該堅持使用集成測試？

來源

2008-12-02 Sam Holder

看看測試是什麼樣的。如果你只測試數據庫中是否有最終結果等等，你可能只是做自動化集成測試來做正確的事情。如果您想測試邏輯，那麼您可能需要考慮是否可以將邏輯分解爲單獨的類，以便您可以圍繞不包含邏輯的基礎結構代碼進行單元測試和外觀測試。

來源

2008-12-02 09:51:28 Mendelt

這是一個好主意，模擬出m_api在我的原因如下代碼（並不是所有的應用到你的僞代碼示例）：

正如你所說，你可以驗證你的類正確執行錯誤處理
如果您的類中存在更復雜的代碼（例如緩存），則可以在模擬中使用期望以確保類正常運行。例如，檢索兩次相同的對象，但確保只調用一次m_api。
您的單元測試可以在不創建適當的數據集的情況下測試行爲。隨着m_api下的數據模型的變化，這會隨着時間的推移增加可維護性。

來源

2008-12-02 09:48:04

基本上持久化的單元測試代碼 - 我應該打擾嗎？

回答

相關問題