開發團隊測試的難與易

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

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

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

      最終咱們的團隊仍是沒有強制單元測試，也許有程序架構的問題，也許有項目週期太緊張的問題，可是我以爲更多的是大多數人沒有認識到單元測試對一個大系統重要性，甚至寫好程序自我測試都作不到，自信到老是來來回回的不停發佈新的fix版本。

      也許是我深受其害，也許是我很在乎別人對我程序的見解，我儘可能要求本身在寫代碼時作好單元測試，在完成程序時本身多測測，多運行，多點點。由於我以爲這樣當我提交本身的模塊，本身的程序時內心才踏實，否則還真是「擔驚受怕」。

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