自動化單元測試實踐之路

　　自動化單元測試并不是什么新鮮事物，它應該是團隊持之以恒的事情，可能有很多團隊知道如何去做，但是還做得不夠好;還有不少團隊不知道如何去做，甚至有一些舊系統還不敢去重構，還在堅持著Java中的main方法調用的方式來執行，在漫長等待構建結果。

　　本文主要講基于Java項目如何做自動化單元測試的實踐。

　　1 是否值得

　　TestPyramid，如下圖所示：

　　圖-1-1-TestPyramid

　　Unit是整個金字塔的基石(在建筑行業，基石是做建筑物基礎的石頭)，如果基石不穩，Service和UI何談有構建意義呢?只有基石穩如磐石，上層建筑才夠堅固。

　　本來想拿瑞士做鐘表的例子來說明下，但同事說的汽車例子更好。一輛汽車由許多配件組成，如果有以下兩種選擇，你會選擇哪個呢?

　　所有單元配件沒有測試過，在4S店，銷售人員告訴你：剛組裝好，已經開了一天，能跑起來，你可以試試;

　　所有單元配件在生產過程已經經過嚴格測試，在4S點，銷售人員告訴你，已經通過國家認證，出廠合格，有質量保證，你可以試試;

　　答案不言而喻了。

　　實施單元測試，并不代表你的生產效率能提高迅猛，反而有時候阻礙了瞬間的生產效率(傳統的開發一個功能，看似就算完成的動作，增加單元測試看起來無法是浪費時間)，但是，它最直接的是提升產品質量，從而提升市場的形象，間接才會提升生產效率。

　　做產品，到底是要數量，還是質量呢?這個應該留給老板們去回答，看企業是否需要長遠立足。

　　2 關鍵部分

　　自動化單元測試有四個關鍵組成部分要做到統一，如圖所示：

　　圖-2-1-關鍵組成部分

　　配置管理：使用版本控制

　　版本控制系統(源代碼控制管理系統)是保存文件多個版本的一種機制。一般來說，包括Subversion、Git在內的開源工具就可以滿足絕大多數團隊的需求。所有的版本控制系統都需要解決這樣一個基礎問題: 怎樣讓系統允許用戶共享信息，而不會讓他們因意外而互相干擾?

　　如果沒有版本控制工具的協助，在開發中我們經常會遇到下面的一些問題：

　　一、 代碼管理混亂。

　　二、 解決代碼沖突困難。

　　三、 在代碼整合期間引入深層BUG。

　　四、 無法對代碼的擁有者進行權限控制。

　　五、 項目不同版本發布困難。

　　對所有內容都進行版本控制

　　版本控制不僅僅針對源代碼，每個與所開發的軟件相關的產物都應該被置于版本控制下，應當包括：源代碼、測試代碼、數據庫腳本、構建和部署腳本、文檔、web容器(tomcat的配置)所用的配置文件等。

　　保證頻繁提交可靠代碼到主干

　　頻繁提交可靠、有質量保證的代碼(編譯通過是最基本要求)，能夠輕松回滾到最近可靠的版本，代碼提交之后能夠觸發持續集成構建，及時得到反饋。

　　提交有意義的注釋

　　強制要求團隊成員使用有意義注釋，甚至可以關聯相關開發任務的原因是：當構建失敗后，你知道是誰破壞了構建，找到可能的原因及定位缺陷位置。這些附加信息，可以縮短我們修復缺陷的時間。示例：團隊使用了svn和redmine，注釋是：

　　refs #任務id 提交說明

　　每個任務下可以看到多次提交記錄：

　　圖-2-2-相關修訂版本

　　1.所有的代碼文件編碼格式統一使用UTF-8

　　2.上班前更新代碼，下班前提交代碼

　　前一天，團隊其他成員可能提交了許多代碼到svn，開始新的一天工作是，務必更新到最新版本，及時發現問題(例如代碼沖突)并解決;

　　當日事，當日畢，下班別把當天的編碼成果僅保存在本地，應當提交到svn，次日團隊更新就可以獲取到最新版本，形成良性循環。

　　構建管理：使用Maven構建工具

　　Maven是基于項目對象模型(POM)，通過為Java項目的代碼組織結構定義描述信息來管理項目的構建、報告和文檔的軟件項目管理工具。使用“慣例勝于配置”(convention over configuration)的原則，只要項目按照Maven制定的方式進行組織，它就幾乎能用一條命令執行所有的構建、部署、測試等任務，卻不用寫很多行的XML(消除Ant文件中大量的樣板文件)。

原文轉自：http://www.uml.org.cn/Test/201407281.asp