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

步子邁太大，容易扯著蛋。
練習的時候需要養成小步的習慣，工作的時候可以自由切換步子的大小。
當你自信的時候步子就可以大點，當你不太自信的時候就可以立即切換到小步的模式。如果只會大步，就難以再小步了。

測試代碼是否會成為維護的負擔？

維護時也遵循 TDD 流程，先修改測試代碼成需求變更后的樣子，讓測試失敗，再修改產品代碼使其通過。
這樣你就不是在維護測試用例，而是在利用測試用例。

為什么要快速實現？

其實是用二分查找法隔離問題，通過 hardcode 實現通過測試后，就基本確定測試是沒有問題，這時再去實現產品代碼，如果測試不通過，就是產品代碼的問題。
所以小步快走主要是為了隔離問題，也就是你可以告別 Debug 了。

為什么測試代碼要很簡單？

如果一個測試失敗了，修復的時候是改測試代碼而不是產品代碼，那就是測試代碼寫的不好。
當測試代碼足夠簡單時，如果一個測試失敗了，就有足夠信心斷定一定是產品代碼的問題。

什么時候不適合 TDD？

如果你是做探索性的技術研究（Spike），不需要長期維護，而且測試基礎設施搭建成本很高，那還是手工測試吧。
另外還有「可測試性極差的遺留系統」和「使用測試不友好的技術?！沟南到y，做 TDD 可能得不償失。

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

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