從另一個角度告訴你單元測試的意義(4)

生產效率

在那些重Service測試而輕單元測試的項目中，Service測試里的數據安裝缺少易用的腳手架，實際上編寫出來的諸多Service測試猶如行尸走肉，不但沒有測試出缺陷，還降低了測試運行速度，拉長了反饋時間。

實踐證明，很多缺陷完全可以通過單元測試來發現，測試金字塔提出者Martin Fowler 強調 如果一個高層測試失敗了，不僅僅表明功能代碼中存在bug，還意味著單元測試的欠缺。因此，無論何時修復失敗的端到端測試，都應該同時添加相應的單元測試。 而越早發現發現Bug，造成的浪費就會越小，單元測試本身就能夠提供了快速反饋的機制。

卓越態度

追求卓越是一個優秀程序員必備的態度。優秀的程序員除了能夠編寫Clean Code，還應該能夠編寫Clean Test。而Clean Code的基本特征之一是易于測試。單元測試可以充當一個設計工具，它有助于開發人員去思考代碼結構的設計，讓代碼更加有利于測試。知名的開源代碼庫從來不會缺乏單元測試，而給與他們自信的也正是這些可觀的單元測試覆蓋率。

考慮到成本與收益比，我們不必保證100%的覆蓋率。因為隨著覆蓋率提升，單元的測試的價值越來越低，而編寫的成本卻越來越高。所以相比于100%這個漂亮的數字，我們應該去追求那不到100%的單元測試的有效性。

夯實根基

單元測試能為代碼庫保駕護航的前提是它本身應該有效可靠。

編寫單元測試的能力容易培養，但編寫有效的單元測試卻需要不斷地刻意練習，甚至一個有多年經驗的Senior開發人員也不一定能夠時刻編寫出有效的單元測試。

讓單元測試有效的一個很好的方式是盡可能讓我們的被測代碼具備良好的可測性。要做到這點，我們需要盡可能的在編碼的過程中掌握必要的代碼設計原則。就拿面向對象的編程編程語言來講，我們在編寫代碼的時候要時刻思考Robert C. Martin

原文轉自：http://sjyuan.cc/significance-of-unit-test-from-other-sight/