單元測試複合功能

Question

說你有3個功能，泛函，functionB和functionC

functionC依賴泛函和functionB

functionA(a) { 
    return a 
} 
functionB(b) { 
    return b 
} 
functionC(a, b){ 
    return functionA(a) + functionB(b); 
} 

現在，這顯然是一個超級簡單的例子..但什麼是正確的測試functionC的方法？如果我已經在測試函數A和函數B，並且它們通過則不會測試函數C，因爲它將依賴於函數A和函數B返回，所以測試函數C不會超過單元測試。

Answer 1

對於您將關注的前兩個函數他們的公共合同 - 您可以根據需要編寫儘可能多的測試，以確保針對不同情況的所有結果都符合預期。

但是對於第三個函數來說，理解函數應該調用其他兩個函數可能就足夠了。所以你可能需要更少的測試。您不需要再次測試測試A和B所需的所有情況。您只需要驗證C負責的預期「管道」。

Answer 2

在我看來你的測試應該不知道 functionC使用functionA和functionB。通常情況下，您會創建自動測試，以支持更改（代碼維護）。如果你改變C的實現呢？所有的函數C的測試也變得無效，這是不必要的和危險的，因爲這意味着，重構者必須理解所有的測試。即使他/她相信，他/她也沒有改變合同。如果你有一個很好的測試，他/她爲什麼要這樣做？因此，functionC的公共契約將被完全測試！

還有一個進一步的危險，如果測試知道太多關於sut（functionC）的內部工作，他們傾向於重新實現裏面的代碼。所以執行的相同（可能是錯誤的）代碼會檢查實現是否正確。 只是一個例子：你將如何實現functionC的（白盒）測試。模擬函數A和函數B，看看是否產生了模擬結果的總和。這對測試覆蓋率（kpi ??）很有用，但也可能會造成誤導。

但是如何測試功能A和功能B的功能兩次的高額外努力。如果是這樣的話，那麼很可能重用測試代碼很容易，如果不可能重用，我認爲這更證實了我之前的陳述。

Answer 3

GhostCat的答案很簡單，很好，專注於必備。
我會詳細介紹一些其他要考慮的問題，特別是重構問題。

---

單元測試集中在API

的類API（公共函數）必須被單元測試。
如果這3個功能是公開的，每個功能都必須進行測試。

此外，單元測試不關注實現，但預期的行爲。
今天，複合功能添加個別功能結果，明天它可以減少它們或其他任何東西。
測試C()複合函數並不意味着再次測試A()和B()的所有方案，這意味着測試C()的預期行爲。

在某些情況下，與單個函數集成的單元測試複合函數不會在單個函數中產生很多重複。
在其他情況下，它的確如此。我將在下一點介紹它。

---

實施例，其中測試所述C()複合函數可能會導致在測試中的複製的關注。

假設A()函數接受兩個整數：

function A(int a, int b){ ...} 

它具有關於輸入參數以下約束：

• 它們必須是> = 0
• 他們是低於100
• 其總和已經低於100

如果其中一個不受尊重，則會引發異常。 在A()單元測試中，我們將測試這些場景中的每一個。每一個可能在不同的測試案例：

@Test 
void A_throws_exception_when_one_of_params_is_not_superior_or_equal_to_0(){ 
    ... 
} 

@Test(expected = InvalidParamException.class); 
void A_throws_exception_when_one_of_params_is_not_inferior_to_100(){ 
    ... 
} 

@Test(expected = InvalidParamException.class); 
void A_throws_exception_when_params_sum_is_not_inferior_to_100(){ 
    ... 
} 

除了錯誤的情況下，我們也可以爲A()功能多正常情況下根據傳遞的參數。

假設B()函數也有多個名義和錯誤的情況。

那麼集合它們的C()的單元測試呢？
您當然不應該重新測試這些案例中的每一個。這是很多重複的情況，而且它將通過跨越兩種功能的情況而具有更多的組合。
下一步介紹如何防止重複。

---

可能的重構來改進設計並降低複合函數的單元測試的重複

當你寫的複合函數，你應該知道的第一件事就是是否複合函數應該不在位於特定組件中。

composite component -> unitary component(s) 

將它們分開可能會改善總體設計並給予組件更具體的責任。
此外，它還提供了一種自然的方法來減少複合組件的單元測試中的重複。
事實上，如果需要，您可以使用存根/模擬酉分量行爲，而無需爲它們創建詳細的固定裝置。
複合組件單元測試可以專注於複合組件行爲。

所以在我們前面的例子，而不是測試的A()和B()所有的情況下，我們的單元測試的C()功能，我們可以存根或嘲笑A()和B()，以使他們的行爲預期的C()場景。

例如，對於與相關A()和B()錯誤情況下，C()測試場景中，我們並不需要重複每個A()或B()情景案例：

@Test(expected = InvalidParamException.class); 
void C_throws_exception_when_a_param_is_invalid(){ 
    when(A(any,any)).thenThrow(new InvalidParamException()); 
    C(); 
} 

@Test(expected = InvalidParamException.class); 
void C_throws_exception_when_b_param_is_invalid(){ 
    when(B(any,any)).thenThrow(new InvalidParamException()); 
    C(); 
}