本文是從 TDD leads to an architectural meltdown around iteration three 這篇文章翻譯而來。

　　這些話來自于我們的軟件領袖Jim Coplien——上世紀九十年代最流行的幾本C++著作的作者。原話是這樣的：

嚴格的按照YAGNI原則的驅動測試開發(TDD)會導致敏捷開發3次迭代結構的坍塌。

　　看到反TDD運動已經形成了一定的氣候，真是讓人感到非常的振奮，我特別喜歡Jim和Bob Martin 之間的爭論，Bob Martin，這出了名的TDD極端主義者，認為任何一個程序員，只要所寫的任何一行代碼沒有使用TDD，就不是一個專業的程序員。

　　Jim 和 Bob 最近的一次非常有趣的辯論，你可以在InfoQ找到他們的辯論記錄。我很敬佩Jim在面對Bob時表現出來的禮貌和克制，因為當你的觀點和Bob不一致時，他的言論永遠都讓你難以忍受。

　　TDD已經讓我糾結了很久，你可以從InfoQ上發布的我的一場被叫做Designing for Testability的演講，或從我最近和Hani Suleiman 一起合著的書里看到我對TDD的某些效果的質疑、甚至是反對。

　　我已經說過，別指望我會跟 Bob Martin 唱對臺戲。我絕對沒有意思說你要永遠別使用TDD，但我相信，TDD所帶來的好處被過度的夸大，軟件社區的人需要明白，TDD只是一種工具，對于一種工具，并不是所有的情形下都會好用。我特別不喜歡TDD極端主義者們的四處鼓噪、妄圖使那些沒有使用TDD的程序員感到沮喪，或使他們認為他們現在開發軟件所使用的方式有什么不對。

　　如果讓我說，我感覺大多數的TDD極端主義者在各種會議上說的太多太久了，已經不用動腦子就能舉例寫出一堆的用來計算保齡球得分的類和代碼程序。而這些卡通式的小程序很容易，它們讓TDD很風光。但是，當這些聽眾離開會場后撓著頭納悶如何讓這種技術應用到自己的真實工作中時，你不要吃驚。如果你使用TDD去開發手機應用程序或去跟需要處理遍布三大洲的上百萬的兩階段提交事務的主框架進行交互的程序時，你算是撞上頭彩了。

　　我不知道你的感覺如何，反正我是有點厭倦了軟件社區里的這種危言聳聽 —— 無論它是來自TDD狂熱分子還是來自那些聲稱絕不招聘不使用Mac做開發的人的人。

　　當需要進行測試時，我信守下面的經驗主義的做法：

• “先測試”還是“后測試”并不重要，只要你是在測試。
• 在你的開發過程中盡可能早的考慮測試。
• 不要讓某個框框限制了你的行動。例如，不要輕信那些人告訴你的、要寫出“盡可能簡單的能夠運行的程序” —— 也就是所謂的YAGNI —— 的話。如果你的經驗告訴你，未來你會用到這個額外的類 —— 雖然現在用不著，你應該相信你的判斷，加上這個類。
• 記住，功能測試是真正對用戶有意義的測試。單元測試只是為你開發者服務的。屬于奢侈品。如果你有時間去寫單元測試，那最好了：當你的程序出現問題時，它們能幫助你省去很多時間。但如果你沒有時間，你要確保功能測試能覆蓋到你的產品里用戶所期望的所有功能點。
• 如果你沒有做測試驅動開發，不要有任何的不安。有太多的因素都能導致這種開發方法在眾多的項目和個人開發習慣中水土不服(有很多因素那些TDD極端主義者們永遠都不會提)。

　　不要讓那些極端主義者把測試搞得痛苦不堪，如果你能運用自己的判斷來實踐它們，這將會成為你職業表現在最有價值的品行。

it知識庫：測試驅動開發(TDD)跟敏捷開發有沖突，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。