我認為，關于這些實踐的許多主張缺乏實際項目經驗，很?難讓人相信他們的觀點。事實上，當我們把這些非常嚴格的測試實踐應用于大型項目上時，通常它們根本無法順利工作。
在本文中，我將說明一些關于測試的常見誤解。我希望，如果你在編寫測試時也存在這樣的誤解，那么本文能幫助你和你的團隊來判斷何時適合測試，何時不適合測試。
測試可以表明我的代碼是正確的
雖然這種誤解在直覺上是正確的，但是你確實無法依賴測試來建立任何形式的具有嚴格正確性的標準。每當你編寫了一個測試，你就已經測試了程序中的 一種可能情況。
當程序中存在許多單元時，或許存在無限多種（或是多得難以應付的）可能的情況需要測試時，那么測試所有可能情況是不可行的。因此，典型的對 策是測試一些出錯情況、邊界情況以及若干恰好確保一切正常的常規情況。
如果你的目標是正確性，那么上面談到內容還遠不足以滿足要求。盡管程序仍存在許多bug，但是開發一套總是可以通過的測試還是相當容易的。
然而 有些bug根本不可能通過測試檢查出來，其中競爭條件和包括并發性在內的其他錯誤都是經典的例證，即使你已經對調度程序進行控制，然而可能的交錯操作的數 量增長是如此之快，以至于可靠地測試很快成為了不可能完成的任務。
因此，測試無法展示所有情況下的正確性，除非是在最普通的情況下，那樣我們可以在測試中完全指定程序單元的行為。
對于這些普通情況，往往不值得 從一開始就編寫測試；之所以說這些情況實在是太普通了，是因為我們所要測試的代碼本身就是微不足道的！
通過為那些微不足道的代碼片段編寫測試只完成了一件 事，那就是增加維護開銷，并且為測試機增加工作量。
既然測試也只是一些代碼，那么在你的測試中同樣可能存在bug。如果編寫測試與編寫代碼的是同一個人，那么他們往往可能錯誤地實現一個程序單元，然后編寫一個確保那個錯誤行為能夠通過的測試。此問題的根源在于開發者誤解了規格說明，而不是實現過程中犯下的小錯誤。
如果你確實需要保證正確性，那么請對你的代碼進行形式化驗證（目前的驗證工具要比過去好得多）。如果你不需要保證正確性，那么編寫測試就可以了。須牢記，編寫測試的作用就如同煙霧報警器對于火災的作用一樣，其實它并不能檢測出各種各樣的問題。
測試是可執行的規格說明
基于以下幾個原因我認為這個觀點是錯誤的。先來看看在我的字典里規格說明的定義：
一組需求，用于界定對于某一對象或過程的準確描述。
因此，如果我的代碼符合規格說明的要求，那么它就應該是完全正確的，因為規格說明準確界定了代碼的行為。如果說我的測試是規格說明，那么必須進而證明測試的正確性。正如我們已經討論過的，測試并沒有做這樣的事情，因此測試不是規格說明。
讓我們看下實際情況，假設一名開發者通過閱讀測試用例可以推斷出某個函數的預期行為，然后引入一大堆含混不清的測試用例；如果測試用例不夠全面，那么我們可能最終推斷出錯誤的結論，有時可能與預期行為僅有細微差別。
此外，對于測試用例并未進行一致性檢查。也就是說，由于開發者失誤或誤解，因此你的測試可能實際指定了一個非預期的行為。這可能會導致在你的測試中出現一些矛盾，因此也可以說你的規格說明中出現了矛盾。
隨機測試軟件，例如QuickCheck，會讓編寫測試的工作變得非常簡單，就像本應包含的布爾屬性一樣，而且該軟件會為你生成測試用例。該軟件使得測試更接近于可執行的規格說明，不過它仍然不會對屬性進行一致性檢查。
測試會讓我們擁有良好的設計
當讓一個糟糕的設計可以測試時，此設計仍然具有改進的可能，因此測試不是優良設計實踐的替代品。
當為系統接口編寫大量的測試時，實際上是增加了 開發者投入在那些接口上的工作投資。當這些接口不再是最佳選擇時問題就會隨之產生，即開發者已經為那些接口編寫了大量測試。
改變接口也就意味著改變所有與 之配套的測試。由于測試與那些接口緊密耦合在一起，因此其中大多數測試將必須被廢棄并重寫。
既然大多數開發者的成長依附于他們所從事的工作，這會導致在項 目的生命周期中對于那些次優的設計決策躊躇不前，盡管那些決策不是最適合的。
在這里給出的解決方案是，只有在你編寫了一系列原型之后再開始著手測試。這樣你就不必為測試那些可能在稍后會被大量重構的代碼而焦慮。
對于開發 者和測試機而言，所做的一切都是在增加工作量，而且當需求或接口改變時，開發者必須銷毀數小時的工作成果，這會使他們更心痛。而如果你不等待而進行了測 試，那么你的測試實際上會導致糟糕的設計，因為開發者將不愿進行任何重大的重構。
此外，讓代碼可以測試很困難。通常人們僅僅為了讓測試更加容易而采用有問題的設計決策；嘗試大量模擬接口實現，或者是編寫具有大量代碼的測試用例，以至于測試用例代碼本身幾乎也需要測試，這些做法都暴露出對于抽象的泄漏（mock對象和stub往往會經受此問題的折磨）。
測試會讓更改代碼更容易
測試并不總是讓更改代碼更容易，然而，如果你正在對底層接口實現進行修改，那么測試可以幫助你捕獲新實現中的功能衰退或非預期的行為。
如果你正 在對程序的更高層次結構進行修改，然而這種對立的情況則是更普遍的現象。測試通常與更高層次接口緊密耦合。改變這些接口就意味著重寫測試。
在那種情況下， 你讓自己活得很辛苦你將必須重寫那些測試，從而給自己增加了更多的工作，而且之前的舊測試對于確保你沒有引入功能衰退而言無能為力，這意味著測試根本幫不 上忙。
所以，不寫測試？
我沒有說你不應該編寫測試。對于提高信心以及阻止軟件功能衰退而言，測試是一種有價值的方式。然而，測試無法統一帶來優良的設計、正確性、技術規格說明或者輕松地重構，至于原因如上所述。過度使用測試會讓開發變得*更難*而不是更容易。
同樣，根本不驗證代碼會讓質量保證無從談起，不過會讓快速構建原型更輕松。測試在質量保證與靈活性之間引入了一個權衡問題，所以我們必須在二者之間做出適當的妥協。
end
推薦閱讀：
