什麼樣的單元測試在商業價值中獲得最大回報？

我的問題假設人們已經相信某種單元測試是值得的，並且實際上將它們寫入他們當前的項目中。我們還假設代碼的某些部分的單元測試不值得編寫，因爲它們正在測試微不足道的功能。例子是getters/setter，和/或編譯器/解釋器會立即捕獲的東西。相反的假設是「有趣的」代碼值得測試。什麼樣的單元測試在商業價值中獲得最大回報？

來源

2009-02-18 Alan

代碼區域的覆蓋水平應該與更改可能性和依賴於它的功能量的組合成正比。

例如，我們的基本控件類的核心有一些相當複雜的解析邏輯。我們單元測試了絕對的小便，因爲它必須處理來自我們影響之外的系統的輸入（很可能發生變化）+我們所有的UI控件都依賴於它的穩定性。基地中最輕微的調整波及通過繼承和依賴層的放大。

來源

2009-02-18 05:10:27

「我們單元測試它的絕對小便」 - +1的美妙轉向！ – 2009-02-18 09:42:26

的單元測試驗證層之間傳遞的數據往往最大價值

UI < ---->商業< --->數據

來源

2009-02-18 05:10:59

若要在我自己的問題了一槍，這裏是我發現值得測試的模塊：

a）任何業務規則。在我當前的應用程序中，業務規則是從業務對象外部化的。

b）業務對象上的任何虛擬屬性。這些虛擬屬性常常涉及算法。

c）我們可以陳述給定輸入消耗的預期產出輸出的主要組件。通常這會滲入集成測試。

d）我們的開發過程要求我們檢查單元測試是否有新功能和錯誤修復。對於錯誤修復，我們試圖複製到底是什麼導致了錯誤，並顯示單元測試可以通過一旦代碼修復簽入英寸

e）我們的任何翻譯層，我們從一個數據表示類型翻譯到另一個作爲POJO-XML

來源

2009-02-18 05:11:25 Alan

我發現最有效的測試是測試以前發現的錯誤的測試。在我看來，如果一個團隊在修復漏洞時加入迴歸測試，那麼他們會比其他幾乎任何測試策略都付出更多的代價。

通過測試已損壞的東西（並徹底測試），您知道您正在測試易於破損的區域。

這當然假設您正在測試在開發過程中中斷的事情，而不僅僅是等待QA報告在部署或類似事件後緩慢進入。

來源

2009-02-18 05:35:00

討論於SO Podcast 41 - 此部分目前未在transcript中。博客中的回覆包含對單元測試覆蓋率值的進一步討論。

喬爾擔心過多的TDD（比如，從90％增加至100％的測試覆蓋率）削減從可能有利於軟件產品的其他活動，如更好的可用性或附加功能的用戶所渴望的時間。

單元測試作爲「吃自己的狗食」的形式絕對有用，並且記錄了系統的行爲。即使您完全忽略了測試的實際結果，它們仍然作爲文檔很有價值，併爲您提供了有關代碼庫的全新外部視角。

Joel指出測試UI（Web或可執行文件）與測試UI背後的代碼的難度。執行此操作的經典方法可能記錄在「UNIX編程藝術」中，其中您從一個命令行應用程序開始，該命令行應用程序接收並分出文本。 GUI只是一個粘貼在命令行應用程序之上的圖層，從而導致完美的可測試性 - 但從長遠來看，可能不是那麼棒的應用程序。哪一個更重要？

來源

2009-02-18 06:46:39 gimel

在列出播客時寫下了這個問題（和我的答案）。我傾向於在這個問題上與鮑勃馬丁站在一起。更多的測試是更好的，但我當然可以聽到Joel關於脆弱的測試問題。 – Alan 2009-02-18 21:01:15

隨着問題的提出，我毫不懷疑像硒測試這樣的功能測試提供了最大的商業價值。通過應用程序單擊硒（Web）測試並確定預期行爲，如用戶故事/用例所定義的那樣。這些測試表明你的軟件試圖與客戶溝通的主要「事情」是好的。

如果這些事情不起作用，您的客戶將失去對生產可信軟件的能力的信心，從而帶走相當數量的商業價值。

現在可能有相當多的細節，這些測試不包括在內，但我真的相信它們在創建信任時尤其重要，特別是在與大衆市場交談時。

來源

2009-02-18 07:30:13 krosenvold

所有合理的單元測試都很有價值，但那些傾向於節省大部分時間的經驗，因此產生最佳的投資回報率，是針對錯誤修正的單元測試。主要是因爲這些錯誤修正適用於代碼中最困難/最脆弱的部分。

來源

2009-02-18 08:08:03