單元測試別名方法

Question

單元測試一個只調用其他2個方法而沒有邏輯的方法的最佳實踐是什么？

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    return FunctionC(b);
}

_factory.FunctionB()和FunctionC(b)都有單元​​測試，所以如果這些方法破了我們就知道了。

我正在考慮偽造這兩個函數，只是進行一個單元測試，確保從FunctionA()調用這些方法。 但是如果FunctionB()或FunctionC()發生變化， FunctionA()可能會變成誤報。

Answer 1

我傾向於不對單個測試私有或內部方法進行單元測試，因為它們應該在單元測試公共API時執行。

假設這是一個公共方法，我會根據私有成員_factory的狀態檢查調用FunctionA（）時所期望的返回值。 假設你可以控制_factory的輸出（通過它是一個可模擬的接口，可以繼承子類的基類，或者只是用已知值實例化並傳遞給類的構造函數），你可以確保獲得預期的輸出FunctionA基於該初始輸入。

如果您發現每次更新FunctionB或FunctionC時都會出現誤報，我會質疑為什么FunctionA存在。 更可能的情況是，在FunctionA上中斷的單元測試將導致您更改FunctionA的內部實現，因為對FunctionB和FunctionC的更改不再使它們成為FunctionA的合適實現，或者它們將導致您添加單元測試那些修復FunctionA間接破壞的功能。

在這個具體的例子中，似乎FunctionA只是一個包裝器，用於將ObjB轉換為具有已由內部工廠類指定的數據源的ObjA。 對於這個特定的場景，我會為FunctionA設置我的測試，以便在上層需求發生變化時（因為實現了如何將ObjB轉換為ObjA的新規則），以便我可以將新邏輯放在FunctionA或FunctionC中，具體取決於哪個我認為更合適。

例：

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    // in the future unit test may drive that a different implemetation is used 
    // based on some data about b.
    if(b.SomeCondition())
        return FunctionC(b);
    else
        return FunctionD(b);
}

或者可能是C需要改變

internal ICollection<ObjA> FunctionC(IEnumerable<ObjB> objBEnumerable)
{
    ICollection<ObjA> objACollection = initializeCollection();
    foreach(var objB in objBEnumerable)
    {
        //updated logic to create objA from objB goes here
        objACollection.Add(createdObjA);
    }
    return objACollection;
}

基本上你的問題的答案是“它取決於”，但如果函數B和C的覆蓋已經很好，如果A需要在未來的第一個代碼示例中轉移，我會錯誤地編寫一個可能無意義的測試。