TDD中的單元測試

Question

我對TDD相當陌生，我想到的第一個問題是我是否應該對每個開發的組件應用單元測試。我在問，因爲我觀察到單元測試需要很長時間，尤其是在提供了對需求的一些更改時。那麼，您能否提出類似於TDD關於單元測試的最佳實踐？

Answer 1

TDD的簡短描述在three rules表示：

1. 你不允許寫任何生產代碼，除非它是使一個失敗的單元測試通過。
2. 你不允許再寫一個單元測試，而不是足夠失敗;編譯失敗是失敗的。
3. 您不允許再編寫比足夠通過一個失敗單元測試更多的生產代碼。

和較長的描述：http://jamesshore.com/Agile-Book/test_driven_development.html

和更深入的描述：http://www.growing-object-oriented-software.com/

Answer 2

TDD意味着測試驅動組件的開發。您首先編寫指定組件行爲的單元測試，然後實現該組件。因此，要回答你的問題：

應適用單元測試，每 開發組件

沒有，因爲單元測試應該已經在開發組件之前被寫入。

Answer 3

測試驅動代碼的開發。 TDD的確全部是關於定義軟件的期望行爲，事實上它全部可測試只是一個好的副作用。

在TDD好文章，請here

Answer 4

只是一個觀察 - 你說

我觀察到，單元測試需要 大量的時間

這是真實的短視圖。但對於將要出現一段時間的代碼，額外的工作可以節省時間。我強調了幾年前我在一個項目上進行單元測試的價值，告訴每個人都會聽，「我們沒有時間跳過這一步。」這是真的。有很多地方會節省時間 - 測試人員將花費更少的時間測試應用程序，通過任何錯誤跟蹤過程踢出錯誤，您將花更少的時間記住幾星期或幾個月後所做的事情，以便修復錯誤，用戶會看到更少的錯誤，這意味着他們會花更少的時間在破壞應用程序上大喊大叫。您將在凌晨2點在手機上花費更少的時間，希望在用戶進入第二天之前能夠修復該應用。

這一切都涉及到經濟學方面。對於任何正在進行生產的代碼，請相信我，您沒有時間跳過此步驟。這會花費你更多的時間和你的公司更多的現金。

如果代碼不會生成，也就是說，它是一個您爲了完成某項任務而編寫的實用程序，或者看看網絡層是如何工作的，您希望調整您爲滿足需求所做的測試量。經驗將有助於指導你在那裏瞭解適量。