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

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

嚴格的按照YAGNI原則的驅(qū)動測試開發(fā)(TDD)會導(dǎo)致敏捷開發(fā)3次迭代結(jié)構(gòu)的坍塌。

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

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

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

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

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

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

　　當(dāng)需要進行測試時，我信守下面的經(jīng)驗主義的做法：

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

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

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

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