常見的TDD Bad Smells
TDD Process Smells
http://agileinaflash.blogspot.com/2009/03/tdd-process-smells.html
Tuesday, March 31, 2009
Posted by Jeff Langr
Published in Agile: In A Flash
作者列出一些常見, 執行TDD會遇到的問題:
1. 使用code coverage的結果當作目標
- 如果對於新開發的codes, 即使在沒有code coverage tool的狀況下, 也儘可能要100% coverage
- 但是對於legacy code, 這可能是另外一件事情.
- 如果堅持coverage ratio number可能會有一些不好的事情發生:
* Coverage comes up quickly by virtue of lots of poorly-factored tests;
* changes to the system break lots of tests simultaneously;
* some tests remain broken, destroying most of the real value in having an automated test suite.
2. 測試時間超過10 分鐘
- TDD最常見的誤解是有關於test size.
- TDD的目標是要利用最短的步驟來產生可以actionable feedback.
- 若是超過10 min, 會讓你不容易從中再學到教訓, 建議要分割你的測試
3. 沒有失敗的cases先處理
- 觀察失敗的cases可以讓你知道原先你認為正確的東西是否仍然正確
- 在TDD的cycle中, 最浪費的事情是, 你一直忽略red bar的警告. 因為這些潛在或是小的錯誤, 可能會讓你日後付出慘痛的代價
4. 沒有花相當比例的時間在refactoring上面
- 如果你花5 分鐘寫code, 你至少也要花好幾分鐘去做refactoring.
- 即時你的程式寫得很好, 也要花點時間看看前後的程式的關連性
5. 忽略一些簡單的東西而沒有去做測試
- 簡單的東西通常會掩蓋掉一些問題, 例如: 有時候你只是認為它只是個"simple getter", 但沒想到忘記要做初始化, 就return給別人使用.
6. 建立你的測試在受測的methods上面, 而不是在其背後的behavior上
- 這是剛開始做TDD時, 常見的嚴重問題
- 一般都只是利用相同的測試程式碼, 去驗證不同資料是否正確而已
- 要確認當初的user story的behavior才是重點.
7. 沒有先撰寫測試的程式碼
- 根據定義, 那並不是TDD.
- 初學者很容易沒有遵守, 而回覆到舊的習慣
留言列表
