Test-Driven Development？別逗了

此文轉載自：http://coolshell.cn/articles/5531.html

——————————————本文開始——————————————

對於程式員來說有些事有非常危險的訊號（red flag）。當我聽到有人開始信仰Test-Driven Development 是 One True Programming Methodology（唯一正確的編程方法論），這就是危險訊號（red flag），我開始假設你是一個劣等、沒有經驗的程式員，或是某些敏捷諮詢師。

測試只是一個工具來協助你，而不是用來證明誰比誰更虔誠，或是我的屌比你的要大，等這種愚蠢的行為。測試是用來讓程式員得到有協助的、更快的反饋，從而找到正確的路徑，如果你搞壞一些事，其還可以用來給後人一些警告。這根本就不是一個神秘的有魔力的方法其可以讓你的代碼變得更好……

整個Test-Driven Development的概念是麻痹和信奉，從而讓其成為你的人生觀。相反的：Developer-Driven Testing，它給你和你的同事一些有用的工具來解決問題，來支援你自己，而不是那種以工具或方法為中心的讓你假設其應該是那樣的測試。

是不是在有些時候我們需要在寫代碼前寫測試？當然是，比如，“修改已有的功能”，這會一個適用的情境，還有那些短小的和已定義完善的事物，或是對已被測試過的代碼做一些改善。

但， 是不是你就應該需要總是要去先寫測試？省省吧，別逗了。

這是極度白癡的行為，尤其是在設計，調查和開發的初期。讓你的測試來接管你的代碼（而不是影響那個模組的代碼）和接管你的設計 這是一個巨大的失敗，就是因為你寫的那些測試範圍太大太不靠譜。（陳皓註：我在《TDD並不是看上去的那麼美》一文中說過測試案例的測試範圍的問題，敏捷社區除了對我進行人身攻擊外從未對此做過正面回答。）

在寫代碼前寫測試案例在一些情境下的確很不錯。然後，Test Driven Development，被敏捷專家或是其它各種五花八門的江湖騙子像神給凡人宣揚一樣，這就是欺騙福士。

行動在想法之下，於是測試必需先行（所有我已看到的，所有我正在看到的都表明這是TDD的中心思想—— 你寫了測試，然後你再寫代碼並通過測試），於是測試成為了最有用的活動並可以協助程式員。這是錯的。

就算你在一開始要寫一些測試案例，但只要你想讓這些測試案例更有意義，那麼，你要麼得讓這些測試案例的測試範圍更小更底層更精確，要麼你就得在整個軟體快要寫完的時候再去寫測試，要不然你就得欺騙或是篡改測試案例。在為數不多的情形下，前者是正確的——測試圍繞於bug，或是小的，定義地很好的功能片段（陳皓註：我個人理解為單元測試是目前最有效））

把測試變成整個活動的中心因為其對程式員有用？真牛逼。老實說，控製程序員的工作流程只可能得出一條無比正確的答案——荒謬可笑。

測試協助程式員，是因為其可以幫程式員組織自動化測試，所以才幫了程式員，而不是cargo-cult（貨物崇拜，參看《各種流行的編程方法》中的cargo-cult編程）——信仰一種工作流程並讓所有的人或事來適應於他。

先寫測試這種方法只會在“Developer Driven Testing”（程式員自己驅動的測試）下可行——關注於選取一個正確的方法讓程式員更有生產力。產生一堆測試的規則並說這是唯一的真理是不正確的。

一些討論和想法（在此貼發出數小時後）…

當我這篇博文發出幾個小時後，其被轉到了別的地方並引發了一些討論。

在 Hacker News 上，有人說我提出了很多很不錯的問題，並且那是真正的有理有據的觀點。我在用使用者名稱叫peteretep 的回複了一些。

在 Reddit 上的爭論更多更強。那裡有很多的人覺得需要寫自動化測試。並且這篇博文被大家演變成擁護測試和可實踐的建議，我覺得我是誤傳達了我的想法，我覺得軟體測試是非常重要的，而不是根據哪個方法論進行的教條主義！