爲什麼功能測試不夠？單元測試提供什麼？

Question

我剛剛與我的首席開發人員進行了一次對話，他們不同意單元測試是必要的或重要的。在他看來，具有足夠高代碼覆蓋率的功能測試應該足夠了，因爲任何內部重構（接口更改等）都不會導致需要重新編寫或重新查看測試。

我試着解釋，但並沒有走得很遠，並認爲你們可以做得更好。 ;-)因此...

功能測試不提供單元測試代碼有什麼好的理由？如果您所有的功能測試都有什麼危險？

編輯＃1感謝您的所有好的答案。我想通過功能測試補充說，我並不是說只對整個產品進行測試，而是對產品中的模塊進行測試，而不是對單元測試的低級別進行測試，如果有必要的話，嘲諷等。我們的功能測試是自動的，並且持續運行，但它們只比單元測試花費更長的時間（這是單元測試的一大優點）。

我喜歡磚與房子的例子。我猜我的主要開發者被說是測試房子的牆壁就足夠了，不需要測試單個磚... :-)

Answer 1

關閉我的頭頂

• 單元測試可以毫不費力地重複。一次寫入，運行數千次，無需人工努力，反饋速度比功能測試快得多
• 單元測試測試小單元，因此請立即指向發生錯誤的正確「扇區」。功能測試指出了錯誤，但它們可能由大量模塊引起，即使在合作中也是如此。
• 我幾乎不會將接口更改稱爲「內部重構」。界面變化往往會破壞很多代碼，並且（在我看來）強制一個新的測試循環而不是一個循環。

Answer 2

如果功能測試失敗，找到問題的根源要困難得多，因爲您每次都有效地測試整個代碼庫。相比之下，單元測試將潛在的問題區域劃分出來。如果所有其他單元測試成功，但是這一個，則可以確保問題出現在您正在測試的代碼中，而不是其他地方。

Answer 3

在開發週期中應該儘快捕捉錯誤 - 將錯誤從設計轉移到代碼，或者代碼進行測試，或者（希望不是）測試生產會增加修復所需的成本和時間。

我們的商店僅爲這個原因執行單元測試（我確信還有其他原因，但這對我們來說已經足夠了）。

Answer 4

單元測試主要是針對開發者，看看那裏的代碼失敗

功能測試是爲商家看看代碼做了什麼，他們問

Answer 5

單元測試主要是針對開發者，看看那裏的代碼失敗

功能測試是爲商家看看代碼做了什麼，他們問

單元測試正在檢查您是否正確製造了磚塊

功能測試正在檢查房子是否符合客戶的需求。

他們是不同的東西，但後者會更容易，如果前者已經執行。

Answer 6

如果您使用純粹的極限編程/敏捷開發方法，單元測試始終是必需的，因爲它們是開發的要求。

在純XP /敏捷一個使得基於其將要執行的應用程序

• 功能測試測試的所有要求 - 生成的功能需求。
• 單元測試 - 生成函數或對象需求。

除此之外單元測試可用於保持對功能要求的持續跟蹤。

即如果您需要更改函數的工作方式，但輸入字段和輸出保持不變。然後單元測試是跟蹤可能的問題的最好方法，因爲您只需要運行測試。

Answer 7

在TDD/BDD中，編寫程序需要進行單元測試。該過程進行

失敗的測試 - >代碼 - >通過測試 - >重構 - >重複

也與文中提到TDD/BDD的好處。總結：

• 非常接近消除使用調試器（我只在測試中使用，現在，很少對那些）
• 代碼不能停留凌亂超過了幾分鐘
• 用於API文檔的例子內置
• 力鬆耦合

鏈路還具有TDD/BDD的（傻）步行通過例子，但它是在PowerPoint（EW），所以here的一個html版本。

Answer 8

假設你已經有已經有一個全面的功能測試，檢查每個可能的用例，你正在考慮添加單元測試。由於功能測試會捕獲所有可能的錯誤，因此單元測試無法幫助發現錯誤。然而，與單元測試，集成測試和功能測試的組合相比，單獨使用功能測試存在一些折衷。

• 單元測試運行速度更快。如果您曾經參與過一個測試套件需要數小時才能運行的大型項目，那麼您可以理解爲什麼快速測試很重要。根據我的經驗，實際上，功能測試更可能是片狀的。例如，有時無頭帽水母瀏覽器由於某種原因無法到達你的測試服務器，但是你重新運行它並且工作正常。
• 單元測試更容易調試。假設單元測試發現了一個錯誤，找出問題的確切位置更容易，更快速。

在另一方面，假設你決定只是保持你的功能測試和不添加任何單元測試

• 如果你需要重新設計整個系統，您可能沒有重寫任何測試。如果你有單元測試，其中很多可能會被刪除或重寫。
• 如果您需要重新構建整個系統，則不必擔心迴歸。如果你依靠單元測試來覆蓋角落案例，但你不得不刪除或重寫那些單元測試，那麼你的新單元測試比舊的單元測試更可能出現錯誤。
• 一旦您已經建立了功能測試環境並且已經掌握了學習曲線，那麼編寫額外的功能測試通常比單元測試，集成測試和功能測試更容易編寫，並且通常更易於正確編寫。