計算機世界裡軟體產品通常是由模塊組合而成的，模塊又可以分成諸多子模塊，子模塊還可以繼續往下拆分，拆分到最終的子模塊是由不可再分的程序單元組成。
對於這些程序單元的測試，即稱為單元測試。本期未名企鵝極客欄目，研發工程師給大家分享的是一些單元測試的基本原則。
單元測試的粒度要根據實際情況判定，可能是類、方法等，在面向對象編程中，通常認為最小的單元就是方法。
在很多人看來，快速完成業務功能開發才是王道，如果開發工程師說需要額外的時間來寫單元測試，並因此延長項目工期，估計有些項目經理就按捺不住了。其實單元測試是一件有情懷、有技術素養、有長遠收益的工作，它是保證項目質量和效率的重要手段之一。
單元測試的好處
（包括但不限於以下幾點）：
1、提升軟體質量
優秀的單元測試可以保障開發質量。在研發過程中執行測試用例，運行失敗的的單元測試能幫助我們快速排查和定位問題，使問題被帶到線上之前完成修復。越早發現的缺陷，其修復成本越低。
2、促進代碼優化
在編寫單元測試的時候，會不斷重新審視自己的代碼，白盒的思考代碼邏輯，更好地對代碼進行設計，甚至想方設法的優化測試用例的執行效率。
3、提升研發效率
編寫單元測試表面上佔用了項目研發時間，但磨刀不誤砍柴工，在後續的聯調、集成、回歸測試階段，單元測試覆蓋率高的代碼通常缺陷少、問題易修復，有助於提升項目整體研發效率。
4、增加重構自信
代碼重構往往是牽一髮而動全身的，有時候只是簡單地修改一個欄位名稱，就會引起一系列的錯誤，但是在有單元測試保障的前提下，可以放心的進行重構。
單元測試需要遵循的基本原則
1、自動化
單元測試應該是全自動執行的。測試用例通常會被頻繁的觸發執行，執行過程必須完全自動化才有意義。如果單元測試需要人工介入檢查，那麼他一定是不及格的。單元測試中不允許使用System.out來進行人工驗證，而必須使用斷言來驗證。
2、獨立性
為了保證單元測試穩定可靠且便於維護，需要保證其獨立性。用例之間不允許互相調用，也不允許出現執行次序的先後依賴。
3、可重複性
單元測試時可以重複執行的，不能受到外界環境的影響。
4、測試顆粒度要足夠小
編寫單元測試時要保證測試粒度足夠小，這樣有助於精確定位問題，單元測試用例默認是方法級別的。單元測試不負責檢查跨類或者跨系統的交互邏輯，那是集成測試需要覆蓋的範圍。
5、測試應該快速
理論上, 任何代碼提交前都應該完整跑一遍所有單元測試，保持測試代碼執行快能夠縮短迭代開發周期。
6、BCDE原則
B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。
C：Correct，正確的輸入，並得到預期的結果。
D：Design，與設計文檔相結合，來編寫單元測試。
E：Error，單元測試的目標是證明程序有錯，而不是程序無錯。為了發現代碼中潛在的錯誤，我們需要在編寫測試用例時有一些強制錯誤信息輸入（如：非法數據、異常流程、非業務允許輸入等）來得到預期的錯誤結果。
7、使用覆蓋率工具
覆蓋率工具能回報你測試策略中的缺口。使用覆蓋率工具能更容易地找到測試不足的模塊、類、和函數。多數IDE都給出直觀的指示，用綠色標記測試覆蓋了的代碼行，而未覆蓋的代碼行則是紅色。這樣就能又快又容易地找到尚未檢測過的if或catch語句。
8、測試覆蓋率的模式有啟發性
查看被或未被已通過的測試執行的代碼，往往能發現失敗的測試為何失敗的線索。
9、立即修正失敗的測試
每個開發人員在提交前都應該保證新的測試用例執行成功, 當有代碼提交時, 現有測試用例也都能跑通。
10、100%測試覆蓋率不是目標
100%的覆蓋率並不能確保沒有缺陷——它只能保證你所有的代碼都執行了，不論程序的行為是否滿足要求。與其追求代碼覆蓋率，不如將重點關注在確保寫出有意義的測試。
總結
單元測試的好處不言而喻，同時我們也要摒棄諸如：單元測試是測試人員的工作，單元測試代碼不需要維護等常見誤解。
未名企鵝內部也存在這樣一種共識：對於開發工程師來講，編寫並維護單元測試不僅僅是為了保證代碼的正確性，更是一種基本素養的體現。
文 / haiyi
編輯 / TiK
關於未名企鵝
未名企鵝以「連接健康」為使命，致力於提供生命健康領域的大數據產品和解決方案，幫助客戶實現數據驅動的業務增長。
未名企鵝中的「未名」代表北大，寓意人文精神，生命健康領域正是體現人文關懷的產業；「企鵝」象徵科技，未名企鵝的創始團隊畢業於北大，技術力量來自騰訊，公司以未名企鵝命名是希望以人文情懷加上科技力量來推動生命科學行業數位化發展。
未名企鵝，數 · 智 · 未來