你真的需要單元測試嗎?

博主最近在接觸一些Android單元測試方面的工作，發現自己并沒有體會到大多數文章所宣傳的“單元測試會帶來工作效率的巨大提升”之類的諸多好處，于是本著批判與自我批判的精神對單元測試做了一番研究，以下言論僅代表個人觀點，如果不足，歡迎指教。

單元測試不是用來找Bug的

當你看到網上諸多關于單元測試的贊美時，仔細看看你就會發現很多說的其實是TDD(Test-Driven Development，測試驅動開發)，不幸的是大多數人并沒有注意區分這兩個概念。在Writing Great Unit Tests: Best and Worst Practices中，Steven Sanderson強烈表達了自己的觀點：Unit testing is not about finding bugs。簡單來說，當先寫代碼后寫單元測試的時候，單元測試就成了一種發現Bug的手段，但作者根據其幾十年的開發經驗指出這種手段其實是十分低效的，因為即使每個功能模塊都能正常工作，但是仍然不能保證模塊之間、模塊與用戶環境之間能正確交互，而后者往往是Bug的主要來源。單元測試或許能找到一些Bug，但相比集成測試和系統測試就顯得十分低效了。
既然如此，那么單元測試為何又備受追捧呢？在How Google Tests Software中，三位谷歌的專家介紹了谷歌的軟件測試之道，總而言之就是谷歌會在開發之初設計好單元測試（其實是用代碼表達需求），在開發中不斷迭代以通過全部的測試（其實是完成全部需求），最終交付給測試人員的軟件已經經過一輪測試，如果還有集成后的Bug，就可以交給專業的測試人員發現了。這是一種典型的敏捷開發，可以看到單元測試扮演更多的是驅動開發的角色。
作為技術標桿的谷歌已經全面引入了單元測試，那么我作為一個普通開發者為什么還要提出一番質疑呢？請看下一節。

單元測試的邊際收益

在經濟學領域，有一個著名的邊際收益遞減規律，指在投入生產要素后，每單位生產要素所能提供的產量增加發生遞減（二階導數為負）的現象。在本文討論的場景中，投入產出如下（引自：軟件開發過程中值不值得寫單元測試？ - voidint's blog）：

成本(投入)

• 編寫單元測試用例所額外付出的時間，短期內會拖慢項目進度。

收益(產出)

• 提升代碼質量。監督開發人員寫出更加易于測試和可維護的代碼。
• 提升開發團隊內部的協作效率。其他開發人員可以通過閱讀單元測試用例來理解代碼原作者的意圖。
• 保證功能實現的長期穩定。代碼一旦發生與原功能意圖不相符的變化，通過跑單元測試可以體現出來，即可以防止功能被無意識地破壞。
• 提高自動化測試占比，降低其他測試方式上的投入。

在經濟學中，邊際收益遞減現象常出現于產量的短期分析中。結合對同事的咨詢以及自己的調研，這個現象在軟件開發領域同樣適用。當我們需要寫原型或者開發一個短期緊急需求的時候，（產品、運營人員）往往要求快速交付，并且由于代碼規模有限也往往不會有太多Bug，在這種短期開發中如果引入單元測試往往會適得其反，投入了雙倍的時間卻沒有明顯的附加收益。而分析How Google Tests Software一書中最多提及的幾個項目（Chrome,Android,Gmail）可以發現，單元測試（更準確說是Test-Driven Development）的成功案例往往都是一些架構設計良好，處于長期迭代開發，基本沒有短期臨時緊急需求的產品，項目初期的單元測試往往在幾年后還能使用，復用率極高（私以為復用率某種程度上可以作為是否值得引入單元測試的標準）。而如果一個項目一開始沒有引入單元測試、過時和糟糕的代碼沒有及時重構、臨時短期需求偏多，往往就沒有引入單元測試的必要了。

Jake Wharton也頭疼的單元測試

Jake Wharton何許人也?答：諸多著名開源項目的作者，Android社區的旗幟人物：
[圖片上傳失敗...(image-547317-1523347911909)]
Jake Wharton對于Android平臺的單元測試也十分頭痛（Against Android Unit Tests

原文轉自：https://www.jianshu.com/p/1980c944e31c