閱讀有關TDD的任何提倡，它總是會歸結為進行自我測試的論點，沒有人反對。從來沒有理由在實現之前編寫測試。這里是執行之前編寫測試沒有理由，所以測試驅動開發從根本上就是錯誤的，因為是倒退。到了2008年下半年，我正在為Windows 7任務欄編寫擴展程序。我的工作基本上完成了，最終的應用程序很小，只有幾屏代碼。我被指示為此編寫單元測試，以便經理可以選中一個框。我拒絕了，因為該項目太小了，沒有任何單元，將其拆開以添加這些愚蠢的測試，將破壞已經通過所有測試并準備發布的工作的穩定性。

隨著談話的惡化，我的經理告訴我有關“測試驅動開發”的新內容，這時我確保有一條通向退出的明確道路，因為我顯然是在與瘋子交談。這是我第一次聽到教理。

　　測試全部通過后，您就完成了

我見過的每一個TDD倡導者都以同樣的空洞信念重復了這個逐字記錄。

　　設計總是在變化

當時我有20多年的經驗，我認識到第一個明顯的缺陷。在編碼之前編寫測試是要記住一句古老的格言：沒有戰斗計劃能夠幸免于敵。我工作過的大多數地方都將軟件計劃視為浪費時間。充其量是他們通過的動作。

在Microsoft，我 多次受到徹底性的懲罰 ，尤其是編寫威脅模型時。但是，我總是從需求 和 功能規格入手來計劃工作，并且拒絕了那些不想花時間在編碼之前進行設計的潛在客戶。

但是，即使是最徹底的計劃，也可能在啟動實施后的幾天甚至數小時之內顯示出意外的突發事件。客戶的設計總是比他們意識到的 還要模糊，即使我盡我所能地勤奮工作，也會有一些我沒有想到的事情。

因此，如果我遵循TDD架構，我將不得不不斷地回顧我的測試，復習所有測試，并根據我的發現修改它們。而且由于在工作完成或接近完成時編寫測試將包括我在實施過程中發現的所有內容，因此事后編寫測試更加有意義。

當然很有趣，一遍又一遍地重寫這些-照片由Elnur Amikishiyev

這是TDD對我來說的樣子：

1.編寫TDD測試

2.開始執行

3.發現意想不到的考慮

4.重寫測試

5.繼續執行

6.goto3一遍又一遍…

7.(實際上更像項目150)所有測試均通過

8.發送到質量檢查

假設，由于TDD，QA部門還沒有全部裁員。請注意，上述4在一個大型項目的過程中可能會發生數十次，并且每次重訪TDD測試都是 100%的浪費時間。

　　老辦法更好

1.開始執行

2.發現意外的問題并加以解決

3.在代碼完成時、編寫測試并運行

4.修復所有錯誤

5.發送到質量檢查

通過這種方法，我在發現冒險之旅之后編寫了測試，因此僅將測試寫到最終設計中，并且僅根據需求重新進行測試。

(1)質量檢查中發現的錯誤

(2)新功能

(3)發布后發現的錯誤

老鼠和男人等的最佳計劃。因為我們都有……

　　盲區

這里的第二個問題是TDD假定開發人員應該編寫自己的測試。 這太荒謬了。我已經看過很多次了;該項目對我來說似乎很可靠，我無法打破它，但是其他人可以在不到一分鐘的時間內打破它，為什么？

因為我的設計中會出現同樣的盲點。

我的腦海只在這里盤旋。沒有人會怎么寫比“是-否”消息框更復雜的東西而不會遇到這種情況？解決此問題之前，無需編寫測試就可以了。無論我在實施之前還是之后編寫測試，都存在我沒有想到的情況，而這些情況不必是“極端情況”。每個人的工作都需要由其他人根據要求和功能規范進行黑盒測試。

討論區

容易想到這樣的態度，即在TDD方案中浪費時間重訪測試只是增加了收入；所以該項目需要20%到50%的時間，那又如何呢？我得到的報酬多20–50%。但是我不認為這是道德的。坦率地說，這很無聊。

以上就是關于淺談測試驅動開發究竟對不對的全內容介紹，想了解更多關于軟件研發的信息，請繼續關注中培偉業。