?做了多年的研發工程師，在所處的環境中，所接觸的開發人員中很少有看重對自己代碼進行測試這項工作的。大多研發人員往往是寫好了代碼運行起來，簡單做下測試，甚至不去測試就拋給接口使用者或者質量管理人員。而且理由很充分“沒時間...；我覺得應該沒問題...；這種簡單的事讓專職人員去測試，否則浪費自己的時間....”從這些話首先該否定的是其人的職業素養，還有就是設計的代碼結構不好測試，或者根本就寫不出好的測試demo。

? ? ? ?記得我們曾經的團隊開始強調測試是在工程漸漸龐大，模塊逐漸細化，人員參與較多時。因為每每在聯合調試時，總是相關人員的噩夢，往往每個人都會被系統的某個bug打斷現有工作，還時不時會出現互相埋怨互相推脫bug責任的情況出現，等定位出bug再分到具體的人頭上。一個bug牽扯到一個團隊，算一筆賬，這個團隊有6個人，假設在自己的模塊中每人平均出現5個bug，這樣在系統中就有30個bug出現，可能在測試過程中每個人會被中斷30次去協助他人定位bug，這種對一個bug而言，非相關人員產生的中斷打擾和時間浪費是明顯和巨大的。當然，我只是舉個例子，現實中也許不會這么極端，往往是兩三個人會出現這種協作情況。但是對相關人員這也是不可忍受的。

? ? ? ?怎么辦呢？引入單元測試，反對聲很大，其中原因主要有兩個：1.如果不和別人的模塊一塊聯合，沒法做測試；2.要自己模擬某種操作還要造數據太浪費時間；第一種情況說白了就是寫不出單元測試，在你做這個埋怨時先看看自己設計的程序，我想如果你如果嚴格做到了高內聚，低耦合；業務和功能分離；或者經典的MVC模型，怎么會做不了單元測試；第二種情況完全就是撿了芝麻丟了西瓜的典型表現，就拿我剛才舉的例子而言，你把時間成本都浪費到后期的聯合調試和定位bug責任人，甚至到了質量部門再因為各種邊界測試，壓力測試找你上門。

? ? ? 最終我們的團隊還是沒有強制單元測試，也許有程序架構的問題，也許有項目周期太緊張的問題，但是我覺得更多的是大多數人沒有認識到單元測試對一個大系統重要性，甚至寫好程序自我測試都做不到，自信到總是來來回回的不停發布新的fix版本。

? ? ? 也許是我深受其害，也許是我很在意別人對我程序的看法，我盡量要求自己在寫代碼時做好單元測試，在完成程序時自己多測測，多運行，多點點。因為我覺得這樣當我提交自己的模塊，自己的程序時心里才踏實，不然還真是“擔驚受怕”。

附件中有我經常使用的單元測試框架gtest的學習文檔，我整理自CoderZh的技術博客