TDD有哪些常見的誤解？

Question

閱讀對這個問題的回答Disadvantages of Test Driven Development?我得到的印象是對TDD是什麼以及應該如何進行誤解。在這裏解決這些問題可能是有用的。

Answer 1

我覺得被接受的答案是最弱的一個（Disadvantages of Test Driven Development?），以及某人可能在指定測試中寫作的最常見的答案氣味之一。

大的時間投資：很簡單 情況下，你失去了實際 實現約20％，但對於複雜的 情況下，你失去更多。

TDD是一項投資。我發現，一旦我完全進入TDD，我輸的時間非常少，什麼時候輸了，在保持時間的時候我輸了很多。

對於複雜的情況下，你的測試用例 難以計算，我建議在 情況下，這樣的嘗試並使用 自動參考代碼，將在平行的調試版本/ 試車運行 ，而不是最簡單的情況下的單元測試 。

如果您的測試變得非常複雜，可能是時候審查您的設計。 TDD應該導致你的行程小，較少的代碼複雜的單位一起工作

有時候你的設計是不是在一開始就很清楚和演變，你走 - 這將迫使你重做測試，將產生大時間輸了。在這種情況下，我會建議推遲單元測試，直到你掌握了一些設計思想。

這是他們所有人中最糟糕的一點！ TDD應該是「Test Driven Design」。 TDD是關於設計，而不是測試。爲了充分認識TDD的益處，您可以從您的測試中獲得您設計的玩具驅動器。所以，你應該重做你的產品代碼，使您的測試通過，而不是倒過來，因爲這一點表明

現在目前最upmodded：Disadvantages of Test Driven Development?

當你到這種地步，你有大量測試，更改系統可能需要重新編寫一些或全部測試，具體取決於哪些測試被更改無效。這可能會將相對較快的修改轉化爲非常耗時的修改。

就像接受的答案的第一點，這似乎超過了測試規範和對TDD過程的普遍缺乏理解。進行更改時，從測試開始。更改新代碼應該執行的測試，並進行更改。如果這種變化打破了其他測試，那麼你的測試正在做他們應該做的事情，失敗。對我來說，單元測試的設計是失敗的，因此RED舞臺爲什麼是第一個，也不應該錯過。

Answer 2

我經常看到的誤解是TDD確保良好的結果。

通常情況下，測試是從有缺陷的需求中寫出來的，因此開發人員生產的產品不符合用戶的期望。在我看來，TDD的關鍵是與用戶合作來定義需求，同時幫助管理他們的期望。

Answer 3

這些都是問題，在我看來是頗有爭議，因此容易產生誤解：

• 在我的經驗，最大的優點就是在大量的時間成本產生更好的代碼，花了編寫測試。因此，對於需要高質量的項目而言，確實是值得的，但在其他一些質量較低的中心站點上，額外的時間將不值得付出努力。

• 人們似乎認爲只有一個主要的功能子集必須測試，但這實際上是錯誤的恕我直言。您需要測試所有內容，以便重構後您的測試有效。

• TDD的一大缺陷是由不完整測試給出的虛假安全感：我看過網站因爲人們認爲單元測試足以觸發部署而下降。

• 不需要模擬框架來做TDD。它只是一種以更簡單的方式測試某些案例的工具。最好的單元測試雖然在堆棧中被觸發得很高，並且應該對代碼中的圖層不可知。在這種情況下，一次測試一層是沒有意義的。

Answer 4

我看到很多人誤解了什麼測試實際上對TDD有用。人們編寫大型驗收測試而不是小型單元測試，然後花費太多時間維護測試，然後得出結論：TDD不起作用。我認爲BDD人員完全避免使用「測試」這個詞有一點意義。

另一個極端是人們停止接受測試，並認爲因爲他們測試了代碼的單元測試。這又是對單元測試功能的誤解。你仍然需要某種驗收測試。

Answer 5

恕我直言對TDD最大的誤解是：花費時間編寫和重構測試會浪費時間。這個想法就像是「是的，一個測試套件很好，但如果我們只是編碼它，功能會更快完成」。

正確完成後，花時間編寫和維護測試在項目的整個生命週期內保存多次而不是用於調試和修復迴歸。由於測試成本在前期，並且回報隨時間推移，因此很容易忽視。

其他一些重大錯誤觀念包括忽視TDD對設計過程的影響，以及沒有意識到「痛苦測試」是一種需要快速修復的嚴重代碼異味。

Answer 6

只是在鍋裏夾另一個答案。

其中一個最常見的誤解是，您的代碼是固定的，即。我有這個代碼，現在我將如何測試它？如果編寫測試很難，我們應該問這個問題：如何更改此代碼以使其更容易測試？

爲什麼..？

那麼該代碼排序，很容易測試：

1. 模塊化 - 每個方法做一件事情。
2. 參數化 - 每種方法都可以接受所需的一切，並輸出應有的所有內容。
3. 嗯特指 - 每種方法都應該做到，不多也不少。

如果我們編寫這樣的代碼，測試是一個輕而易舉的事情。有趣的是，易於測試的代碼恰巧是更好的代碼。

更好，因爲在更易於閱讀，更容易測試，更容易理解，更容易調試。這就是TDD經常被描述爲設計練習的原因。