是否有人對正式的單元測試的實用性有度量？

Question

是否有人對正式的單元測試的實用性有度量？ 我看到很多對單元測試工具的關注，我很好奇為什么？

我在5到6年前就停止了正式的單元測試，生產率的凈收益似乎很高。 我停止了單元測試，因為我注意到它從來沒有捕獲任何東西-更不用說任何有用的東西了。 通過每小時不喝超過2杯葡萄酒/啤酒（或每小時不超過2個關節），似乎可以預防單元測試檢測到的錯誤類型。 另外-單元測試似乎通過允許開發人員認為存在一些可以掩飾其錯誤的保護措施而帶來了風險。

我進行測試以確保代碼能夠正常工作，但是我不使用任何工具。 我根據所做的更改進行測試。 新代碼的生產錯誤率大約為零。 我對代碼更改的錯誤率大約是每季度2-3個錯誤。 以上措施基於我開發/支持的4種生產應用程序。

Answer 1

我承認您是人類和編碼者的優勢。

但是，我只是個白痴，沒有Python單元測試，我會迷路的。

沒有單元測試，我無法重構，這需要太多的思考。

沒有單元測試，我幾乎無法編寫代碼，很難絕對確定我絕對理解每一個細微差別。

我是白痴，所以進行單元測試。 由於您不會犯錯誤，因此您顯然不需要進行單元測試。 我向你們致敬。

---

編輯。 對我而言，單元測試與指標或成本無關。 我不需要任何隨機的，受控的實驗就可以顯示出它的價值。 沒有他們，我無法工作。 確實，我拒絕沒有他們的工作。 同樣，如果沒有編譯器，文本編輯器或源代碼控件，我將無法工作。 沒有要求，我不會工作； 我拒絕不先做設計就編程。

Answer 2

我不認為單元測試可以替代傳統測試，而可以作為確保代碼正確性的額外步驟。 我發現單元測試有用的一些特定領域是：

• 重構/更改現有代碼時。 單元測試將驗證至少那些情況仍然可以按預期進行。 測試次數越多，您就越有可能確定代碼更改不會破壞現有代碼。
• 提交錯誤報告時。 進行暴露一個錯誤的單元測試是演示該錯誤並知道何時修復該錯誤的好方法。
• 一種設計接口的方法。 您有一些測試代碼可以用來檢查接口。

我可能已經忘記了一些其他問題：-P

PS：您如何知道自己沒有錯誤？ 我不認為我會在所處理的代碼中引入錯誤，但事實並非如此。 恕我直言，認為您的代碼沒有錯誤是天真的。

（關於單元測試，如果您知道您的代碼可能包含錯誤-我會說大多數代碼都包含-您是否不想使用一切可能的方法來捕獲它們？）

Answer 3

這是一些有關單元測試的白皮書，可能會對您有所幫助：

• 白皮書＃1
• 白皮書2
• 白皮書3

但是， 馬丁·福勒 （ Martin Fowler）認為，支持單元測試和TDD的軼事證據是壓倒性的，但您無法衡量生產率。

單元測試很好，因為您可以更改零件並知道它是否在其他地方進行了修改。 有些人“愛上了”單元測試，應該讓自己平靜下來。 我相信單元測試，但是那些試圖隱瞞一切的人對於沒有單元測試的人來說是危險的。

Answer 4

我沒有任何指標要指出，但是我認為受歡迎程度的上升是因為我們其他人的經驗與您相反。 :)

Answer 5

這是一個有關TDD方法的研究線索

是否有確鑿的證據證明單元測試的投資回報率？

Answer 6

通過單元測試，我可以修復生產代碼中的錯誤，並在發現錯誤的一小時內安裝新版本，並且可以確定新版本不會比我們以前的版本差-因為測試可以告訴我。 不過可能會更好。

它們給了我較低的水印，低於此水印我的代碼質量永遠不會下降。 它們使我能夠跟蹤大局，並讓測試發現我容易犯的小錯誤。 它們也使我以輕松的方式發展。

自測試以來，我傾向於按時交付，我的代碼質量得到了很大改善，並且結果通常可以按預期工作。 此外，我的速度也快得多，因為我可以偷工減料，如果沒有測試，嘗試將非常危險。

就是說，盡管我多年來一直在進行單元測試和TDD，但我也沒有任何硬性數字，也不知道任何消息來源。 我對測試的熱愛是基於純粹的口口相傳和個人經驗。

Answer 7

我發現添加新功能時，單元測試可以幫助我。 在這種情況下，我曾經擔心添加的內容會破壞應用程序某些遠程部分的內容。 但是通過適當的單元測試，我知道在運行測試的那一刻是否已經損壞了某些東西。

這是關於單元測試的實用性的有趣討論。

如果您不喜歡單元測試，則可能要考慮的另一個概念是“ 按合同設計”。 它基本上斷言，如果滿足某些輸入條件，則根據合同將有保證的輸出。

Answer 8

我是開發經理。 對於我的組織而言，設置和遷移到Nhibernate涉及一些設置成本，並增加了我們的開發時間。 有些開發人員喜歡它，有些認為這是浪費時間。

錯誤率沒有明顯變化，但現在還為時過早。

從我的角度來看，我認為它可以幫助不確定其工作的初級開發人員，但是對於高級開發人員而言，它似乎使他們的速度變慢了-保持更新是一回事。 我不確定我們是否會繼續使用它，恢復到以前的方式（臨時單元測試），還是讓開發人員做出個人選擇。

Answer 9

有幾種工具可用於測試單元測試的代碼覆蓋率。 它們與單元測試一起是必不可少的部分，以確保不僅對代碼進行了測試，而且對它們進行了完整的測試。

其他一切都只是純魔術;）

Answer 10

如果要重構代碼，按照定義，您需要某種方法來判斷更改是否破壞了代碼。 缺乏神聖的見解，我發現單元測試是一個非常好的工具，但是非常好。

Answer 11

我特別在大型的單片服務器應用程序上使用帶有C ++的測試驅動開發（TDD）獲得了很多收益。

在處理代碼區域時，在更改或編寫新代碼之前，我首先要確保該區域已被測試覆蓋。

在這種用例中，我在生產率方面有巨大的收獲。

• 建立並運行我的測試：10秒。
• 要構建，運行並手動測試整個服務器：最少5分鍾。

這意味着我能夠非常快速地迭代一段代碼，並且僅在需要時才進行全面測試。

除此之外，我還利用了集成測試，該測試花費了較長的構建和運行時間，但僅使用了我感興趣的特定功能。

Answer 12

我對你的意思表示同情。 我的經驗相似，因為我的新錯誤很少被單元測試捕獲。 如果有的話，在發現錯誤之后，將對單元測試進行修改，以確保它不會再次出現。

單元測試對我有幫助的地方是我的（Java）類的設計。 我經常重構類以使其可測試（例如刪除單例），我認為這改善了總體設計。 對我來說，這足以使用它們。

Answer 13

以我的經驗，單元測試幫助我完成了以下工作：

• 現在，我可以將所有精力放在正在編寫的代碼塊/函數/類上，而不必擔心其他任何事情，因為我知道如果我做一些愚蠢的操作或引起副作用，我的測試就會告訴我
• 我可以通過知道自己沒有破壞東西來重構東西
• 我確定我的應用程序可以正常運行
• 在發布之前，我不會手動檢查每一項功能以確認該應用程序仍能正常運行，
• 我確定我的應用程序一定程度上一直穩定

但是，這與我有點關系，因為我對“一次管理多個內容”和“集中精力”確實很不好。 因此，單元測試為我工作，實際上節省了我很多時間，在此我引入了一項新功能，但它破壞了一些舊功能。

如果不是這種情況，那就不要使用它。 如果您仍然具有相同的結果，性能和質量以及相同數量的錯誤，那么這意味着您不需要單元測試。 或者您需要修改單元測試方法。

PS根據您的錯誤率以及您所說的聽起來還是個天才（假設這些是中型或大型項目），因此我要說不要使用單元測試，看來您做得不錯。 但是對於像我這樣的天才以外的世界其他地區，我強烈推薦單元測試，因為它對我有用。

Answer 14

Dunno關於您，但是我剛剛檢查了兩個修復程序，以解決由於單元測試捕獲的現有代碼更改而創建的兩個核心轉儲。 如果我對結果有更多的信任，我只是遇到了一個重大的生產問題，而單元測試可能會抓住這個問題（我們的單元測試在功能方面比我想承認的要多得多）。

Answer 15

在我看來，使用流行的測試工具進行的正式單元測試與美國機場安全非常相似。

• 它提供了安全的錯覺
• 它使人們“感覺”良好
• 這非常不方便（如果您弄錯了膚色，則非常不便）
• 如果您批評它，人們會生氣地向您揮動拳頭。
• 當他們的過程失敗時，這些相同的人將被迷惑，他們將跳上下一輛旅行車...

我認為人們對軟件有不同的看法。 在我看來，軟件是一種賺錢的手段（希望通過增加收入或節省金錢）。 我看過有關TDD的帖子，這是我認為是最科學的回答問題的方法，但該方法缺乏科學嚴謹性。 指定的文章都沒有基准或相當對比的替代方法。

我想，正式單元測試的擁護者將繼續以自己的方式感到安全。 我將繼續將規格寫在紙片上，放在我的聖安東尼雕像腳下的碗里，並祈禱。 誰說哪種方法更有效，但是我的方法肯定不錯……也許我會寫一份白皮書。

Answer 16

請記住，70年代和80年代的理發和衣服的流行度上升……對於那些生活在那幾十年中的我們來說，這並不是一件好事。

正式的單元測試需要大量的工作和維護工作。 我猜想，實際開發軟件需要20-50％的時間。 我要問的是每項開發工作都要增加20-50％開銷的已知價格，這是值得注意的和/或可證明的。

通過不進行正式的單元測試，您將迫使開發人員考慮進行適當的測試。 開發人員獲得了產品的更多所有權。

正式的單元測試聽起來像蛇油汁……每個人和他的兄弟都說它很好，有用，很酷，等等，但是還沒有一項隨機對照試驗來證明它確實節省了時間或金錢。 到目前為止，所有答復均為主觀證詞。

我想知道的是，在引入單元測試后，是否有一個軟件經理可以證明更高的生產率（甚至更高的質量）。

大聲笑-S.Lott的惡作劇是獲得最高評價的響應...鑒於該論壇是匿名的（無論如何對我來說），您的尊敬不是我想要的。 我認為自己勉強能做到平庸。 我曾與傑出的開發人員一起工作過……這些家伙通常甚至不對其代碼進行基本測試-他們只知道它會工作。