如果單元測試方法的圈複雜度爲1，如果它們是較大交互作用的一部分，我應該測試它嗎？

我對單元測試很陌生，所以請原諒一個天真的問題。如果單元測試方法的圈複雜度爲1，如果它們是較大交互作用的一部分，我應該測試它嗎？

我聽說過沒有測試具有1的圈複雜度的任何東西的想法。這對我很有趣b/c我在事件之間做了很多交互測試。例如，按下按鈕，觸發事件，在演示者上引發事件，演示者修改模型，演示者在視圖上調用方法。所以我測試以確保當按鈕事件發生時，調用視圖上正確的方法。

此序列中的每種方法的環複雜度爲1.沒有分支。但如果我想測試它作爲一個「系統」（即視圖，演示者，模型），圈複雜度更高 - 將事件序列中的所有1值方法相加。

所以我的問題是，當人們建議我不需要測試具有1的圈複雜度的方法時，他們是不是在討論用於測試類之間交互的交互測試，就像我上面所描述的那樣？

我本週兩次遇到這個想法 - 一次在Mark Seemann Pluralsight視頻中，一次在這裏：http://webquali.com/blog/67/15-ways-to-write-beautiful-code.html。

來源

2017-03-26 Trevor

雖然它可能是有趣的討論，我不認爲它適合SO格式。 – Lanorkin

這是比較教條式的（因爲它主要是基於觀點的，所以對於StackOverflow而言是偏離主題的）。也就是說，如果您無法看到針對方法本身的測試值，那麼通常表示a）集成測試更有用的區域，或者b）您應該對堆棧中的一個或兩個方法進行「單元測試」如果可以在沒有外部依賴的情況下進行完全封裝，則不會成爲真正的集成測試。 –

至於問題考慮例如有1作爲圈複雜度的方法'int Multiply（int a，int b）{return a - b; }' - 這顯然是錯誤的 - 爲什麼你不測試它？我認爲你不應該從「現在它是簡單的方法 - 我不會測試它」，而是從「我應該測試方法合同無論如何不管它有什麼身體」 – Lanorkin

考慮的不是規定性TDD方面的測試，而是作爲一種線索，使您的開發人員能夠確定CI在運行集成時是否會發生意外的行爲變化。

舉一個簡單的例子，你在評論中規定，一個計算器方法：

public int Minus(int a, int b) => a - b;

不編寫單元測試可能會導致有人不小心改變，像這樣的代碼：

public int Minus(int a, int b) => a + b;

這將不可避免地破壞整個應用程序在運行時。

因此，建議通常是：對於團隊中開發人員編寫的每行代碼，有人編寫代碼時，應該有相應的隱式或顯式斷言。

當我們說隱式斷言，我們的意思是，例如：

public object ReturnMytype() => new MyType { MyProperty = "a" };

[TestMethod] 
public void ReturnMytype_SetsMyPropertytoA(){ 
    Assert.AreEqual("a", (new MyClass().ReturnMytype as MyType).MyProperty); 
}

在上述單元測試斷言ReturnMytype返回正確的類型是隱式的（類型轉換）。這一個測試足以證明被測方法的兩種行爲 - 它返回一個MyType，並且它將MyProperty設置爲「a」。

來源

2017-03-26 13:23:55 zaitsman

如果單元測試方法的圈複雜度爲1，如果它們是較大交互作用的一部分，我應該測試它嗎？

回答

相關問題