深度解讀 - TDD（測試驅動開發）(4)

如果違反了會怎么樣呢？
違反第一條，先編寫了產品代碼，那這段代碼是為了實現什么需求呢？怎么確保它真的實現了呢？
違反第二條，寫了多個失敗的測試，如果測試長時間不能通過，會增加開發者的壓力，另外，測試可能會被重構，這時會增加測試的修改成本。
違反第三條，產品代碼實現了超出當前測試的功能，那么這部分代碼就沒有測試的保護，不知道是否正確，需要手工測試?？赡苓@是不存在的需求，那就憑空增加了代碼的復雜性。如果是存在的需求，那后面的測試寫出來就會直接通過，破壞了 TDD 的節奏感。

我認為它的本質是：
分離關注點，一次只戴一頂帽子
在我們編程的過程中，有幾個關注點：需求，實現，設計。
TDD 給了我們明確的三個步驟，每個步驟關注一個方面。
紅：寫一個失敗的測試，它是對一個小需求的描述，只需要關心輸入輸出，這個時候根本不用關心如何實現。
綠：專注在用最快的方式實現當前這個小需求，不用關心其他需求，也不要管代碼的質量多么慘不忍睹。
重構：既不用思考需求，也沒有實現的壓力，只需要找出代碼中的壞味道，并用一個手法消除它，讓代碼變成整潔的代碼。

注意力控制
人的注意力既可以主動控制，也會被被動吸引。注意力來回切換的話，就會消耗更多精力，思考也會不那么完整。
使用 TDD 開發，我們要主動去控制注意力，寫測試的時候，發現一個類沒有定義，IDE 提示編譯錯誤，這時候你如果去創建這個類，你的注意力就不在需求上了，已經切換到了實現上，我們應該專注地寫完這個測試，思考它是否表達了需求，確定無誤后再開始去消除編譯錯誤。

為什么很多人做 TDD 都做不起來？

不會合理拆分任務
TDD 之前要拆分任務，把一個大需求拆成多個小需求。
也可以拆出多個函數來。

不會寫測試
什么是有效的單元測試，有很多人寫測試，連到底在測什么都不清楚，也可能連斷言都沒有，通過控制臺輸出，肉眼對比來驗證。
好的單元測試應該符合幾條原則：

• 簡單，只測試一個需求

  原文轉自：http://www.jianshu.com/p/62f16cd4fef3

  • 共12頁:
  • 上一頁
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 下一頁