觀點：測試驅動的開發從根本上是錯誤的

事件起因

2008 年，我為 Windows 7 任務欄寫了一個擴展插件，最后的應用程序非常小，只有幾頁代碼。完成后，我接到指示，要為這個應用程序寫 單元測試 ，這么做只是為了能讓經理檢查打分。我拒絕了，因為這個項目實在太小了，根本不需要單元測試。而且，為了添加這些愚蠢的測試把應用程序拆成幾個部分，意味著使本來已經通過了測試并準備發布的應用程序變得不穩定。

隨著這次溝通逐漸無法進行，經理告訴了我一些話，即所謂的 “測試驅動開發” ，這時，我下決心要結束這場談話，因為這是我第一次聽到這樣不合理的說辭：

當測試全部通過，你就完成了任務。

我遇見的每一個 TDD（Test Driven Development） 宣傳者都會一字一句地重復上面這句話。

測試什么時候寫？

當時的我已經有了 20 多年的軟件開發經驗，我第一次意識到明顯的缺陷所在，編碼前就寫測試需要記住一點：在與敵人的接觸中，沒有任何戰爭計劃能夠幸存。我工作過的大部分地方都認為軟件計劃是在浪費時間，他們最多也就是走走流程。

在微軟，我好幾次因為在軟件開發中做了周全的規劃而受到懲罰，特別是在寫威脅模型時。但是，我總是從 需求 和 功能規范 開始規劃工作，我拒絕了一些潛在客戶，他們不愿意在編碼前花時間做軟件設計。

但是，即使是最周全的計劃也會在編碼實現后出現非預期的緊急事件，即便在若干小時內不會出現，也會在數天內出現。 客戶們的設計總是比他們認為的更加模糊不清 ，即使是我竭盡全力，也會有一開始想不到的事情發生。

所以，如果采用 TDD 架構，我就得不斷地查看測試，審核所有測試項，確保它們滿足我在項目里的新發現。而如果在工作結束時，或者快要結束時編寫測試，測試項就會包含編碼時所有的新發現。所以，這些都比在編碼完成后寫測試合理得多。

以下是我所看到的 TDD 流程：

1. 編寫 TDD 測試
2. 開始編碼
3. 發現非預期的事件
4. 重寫測試
5. 繼續實現
6. 返回步驟 3 重復、重復、重復……
7. （實際上，要多于 150 條測試）所有的測試都通過
8. 發送到 QA 專區

假設，QA 部門因為 TDD 而沒有被全部解雇。注意上面第四項，在大型項目中，重寫測試可能要出現幾十次，而每次重新檢查 TDD 的測試項都是 100% 浪費時間 。

傳統方式更好

1. 開始編碼
2. 發現非預期事件并修復
3. 編碼完成 ，編寫測試并運行
4. 修復 Bug
5. 發送到 QA 專區

這種方法，我在有了發現之后才編寫測試，因此，測試只針對最終的設計而編寫，只在以下情況發生時重新審核測試：

• QA 階段發現 bug
• 添加新的功能
• 發布后發現新的 bug

問題

這里存在的問題是 TDD 假設開發者自己寫測試程序，這很不合理。我見過很多開發者認為項目非常穩固，但其他人卻能在一分鐘內就攻破它，這是為什么？

這是因為 開發人員 在設計時產生的盲點也同樣會出現在測試中。

有誰會寫一個比 Yes-No 消息框更復雜的功能，卻又不運行它呢？在編碼實現之前就編寫測試，并不會解決這個問題。不管是在編碼前寫測試還是編碼后寫，總有些情況是開發人員預想不到的，這些情況倒不一定是“邊緣情況”。每個人的工作都需要 其他人 根據需求和功能規范進行黑盒測試。

結論

很多開發者可能有這樣的想法：在 TDD 中重新審查測試所浪費的時間會帶來更多收入，項目周期也會增加 20% 到 50%，這會讓收入增加 20% 到 50%。但是，我認為這很不道德。坦率地說，這也十分無聊。

閱讀任何有關 TDD 的宣傳材料，它們都會歸結到測試本身的爭論，沒有人會反對它，它也從不談及在編碼之前寫測試的理由是什么。

原文鏈接： https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d

原文轉自：https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d