最近公司要求重新回顧單元測試的實際效果，作為一個開發經理，我個人對單元測試也有很多疑惑。就個人而言，我自己也寫過很多單元測試，也鼓勵程序員寫單元測試，但實際效果似乎不盡如人意。因此，寫了這篇短文，想和大家一起探討。

1. 背景介紹
我所在的公司是一家外資軟件公司，主要工作是開發一個復雜的在線系統(java based web applicaiton). 該系統的主要特點是：定制化程度比較高，業務邏輯相當復雜。 系統的技術棧是Struts, EJB (JBoss) and Hibernate。我管理的小組一共有10個左右開發人員，6個左右測試人員，平均工作經驗在3年以上。

公司在兩年前開始推行單元測試。在開始推行單元測試之前，系統已經正式上線，也就是意味著有海量的沒有單元測試的代碼。推行之后，應該說投入了相當多的時間，總共覆蓋的行數有20k, 其中行覆蓋率（line coverage）有55%左右，分支覆蓋率(branch coverage)有40%左右。我相信經過這么多嘗試，應該說，我帶的這個組不是一個單元測試的新手，有資格討論單元測試的得失。

2. 實踐中的問題和疑惑（開發人員怎么說？）
      我一向主張：一項技術值不值得或者好不好用歸根結底是要問實際的使用者和開發者的。作為一個經理，我不傾向于推行一項程序員極力反對的技術，不管這項技術是不是業界的標準或者是評論者的寵兒。一項技術必須要解決實際問題，也就是mark your life easier。所以下面是開發人員的回答。
  2.1 為什么需要單元測試和TDD (Test Driven Development)?
     2.2.1 單元測試可以發現代碼缺陷(Defect)么？投入/產出比(Defect count/Effort)是多少？
                只能發現待測單元的缺陷，不能發現單元交互（集成）之間的缺陷。在實踐過程中，很少有defect通過單元測試發現。
                基本不能用于發現表現層(JSP, Java scripts, css, UI etc)的代碼缺陷
                投入/產出比太高。換句話說，相比于單元測試，人工測試(munual testing)可以很大程度得更快更好的發現系統缺陷。
     2.2.2 單元測試可以用來防止Regression Defect么?
                如果我們特地為某個regression defect加了相應的單元測試，那么單元測試在某種程度上可以防止regression defect的再一次出現。但是同樣的，單元測試只能防止待測單元中的Regression Defect，而且需要通過猜測來加入相應的測試案例。
     2.2.3 單元測試對設計有幫助么？
                單元測試本身不一定能幫助設計。據說TTD可以幫助設計，實踐過程中沒有很深的體會。
     2.2.4 你投入了多少時間寫單元測試？需要多少時間維護單元測試？
               單元測試:代碼 = 2：1，也就是說一行代碼需要兩行單元測試。也有些人說1：1。
               維護成本基本上決定于單元接口的變化頻率：對于一些比較穩定的代碼單元，維護成本還可以接受。但對于一些需求變化劇烈的單元，基本上需要重寫。在實際實踐中，可能的比例為穩定的單元測試：重寫的單元測試 = 80%：20%。但是這里有一個悖論：其實我們更希望單元測試可以用于驗證(verify)核心單元的正確性，然而這些單元的測試單元確基本上需要重寫。這是為什么呢？其中一個可能的原因是：對于一個在線系統(web based application)來說，系統的主要邏輯和用戶接口（user interface）綁定過于緊密，所以，用戶接口的變化導致從表現層到數據庫層的垂直變化。即使業務需求只是加了一個新的屬性，但是這個數據將被加入核心的對象當中，所有涉及這個對象的單元測試需要改變。
     2.2.5 單元測試的主要挑戰是什么？
          挑戰之一：如何在多個測試用例之間共享測試數據。
         公司產品支持一個很復雜的在線向導，由七步組成，每一步可以單獨保存然后退出，下次繼續編輯。如果你想測試最后一步的API, 你需要準備很多其他頁面的數據。因此，需要花很多時間準備測試數據。另外，公司產品還支持相似功能的其他向導。作為一個程序員，我們一直想在多個類似功能的向導API之間共享測試數據。然而，如果待測對象本身有些微變化，所有共享該數據的測試代碼全部需要重寫。這是一個巨大的維護費用。
         挑戰之二：劇烈的需求變化導致維護成本劇增，收益減少。
         正如2.2.4中描述的，一個典型的在線系統(web based application)，通?？梢苑譃槿龑樱罕憩F層，主要是用戶界面，包括HTML/JSP/CSS/Java Scripts/Ajex等等；業務層，主要是業務邏輯；數據層，存取數據。根據面向對象設計(OOD)的原則，業務層主要由一組領域對象(Business Object/Domain Object)構成。這些領域對象只提供一組數目相對有限的，接口比較清晰的，時間比較穩定的API。對這組API進行單元測試是有必要的，也是有意義的。
         然而，系統還有相當一部分的代碼用于調用不同領域對象之間的API, 轉變成表現層需要的對象。表現層其他的邏輯還包含大量的代碼用于連接不同的頁面，以及構建不同的向導。 
        正如和絕大多數的系統一樣，產品需求的變化是極其劇烈的，可以預測的，不可避免的。在這種情況下，需求變化將導致領域對象API以上的代碼（包括絕大多數表現層代碼和一部分業務層代碼）將發生劇烈變化，與之相應的單元測試代碼都需要相應的改變。也就是說，這些代碼的單元測試代碼的維護成本很好。
         挑戰之三：海量的遺留代碼(Legacy Codes)
        正如前面描述的，我們是在產品已經上線之后才開始推行單元測試的。因此，大量的遺留代碼并不適用于單元測試。換句話說，單元測試必須要在API實現之前予以仔細得考慮。如果API本身沒有得到很好的設計，單元測試基本上是不可能的。 
     2.2.6 拿什么來衡量單元測試？
          一般來說，業界使用行覆蓋率（line coverage）和分支覆蓋率(branch coverage)來衡量單元測試的測量。但在實際過程中，我們發現這些衡量標準和我們對單元測試的期望有很大差距：比如說，高覆蓋率不見得較少的代碼缺陷。高覆蓋率也不能防止regression缺陷。高覆蓋率也似乎和設計沒有直接關聯。從另外一個角度說，達到高覆蓋率所花費的時間也是相當驚人的。 
      從另外一個角度來說，我們希望找到一個方法可以簡單直接地衡量單元測試的測量：比如說代碼缺陷或regression defect數量。
      
3. 聆聽和討論（業界怎么說）
        帶著這些問題和困惑，我在網上查詢了大量相關資料，牛人的文章和業界的討論。很容易看出，業界對于單元測試的目標，作用，方法和手段都有很多爭議。
    3.1 什么是（不是）單元測試？
         3.1.1 單元測試和發現缺陷無關(http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/)
            【摘要】單元測試不是一個發現缺陷或者檢測regression defect的有效方法。其一，單元測試，根據定義，是用來測試特定代碼單元。然而，一個系統往往是一個大量單元的復雜集成，單元測試很難發現集成的缺陷。其二，相比單元測試，手工測試或者自動化集成測試更容易用于檢測缺陷。
         3.1.2 一個測試不是單元測試 如果 -  
         和數據庫交互
         需要跨越網絡
         需要訪問文件系統
         不能和其他的單元測試同時運行
         需要配置文件才能運行
    3.1.3 測試驅動開發和驗證（verification）無關，和規范（specification）相關
      測試驅動開發并不意味著單元測試驅動的開發。實際上，測試驅動開發這個詞非常容易引起誤解。在TDD的大佬們眼中，單元測試只是測試驅動開發的工具，而不是目的。測試驅動開發更關注這個代碼單元應該如何運行（behave）而不是這個代碼單元實現是否正確（verification）。之所以叫測試驅動開發，意義及在于此。最近你可以看到一個新名字的興起-行為驅動開發（Behaviour Driven Developemnt）。BDD更強調一個組件應該如何工作，以及尋找一個簡易的方法來規范行為。
     3.1.4 為什么需要單元測試？
       可以單獨地測試每個單元
       可以用于驗證重構后的代碼 
       可以用來確保不會破壞其他人的代碼
       可以用來提高系統設計，比如說，不能單元測試的代碼將不會出現               
    3.2 對怎么樣的代碼做（不做）單元測試？
    參考http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/ 
     【摘要】 該文作者在總結3年的TDD實踐經驗的時候，反復認識一個情況：對于某些類型的代碼，單元測試工作得很好，也極大的提高了待測代碼的質量；但對另外一些類型的代碼，單元測試耗費了大量的時間，并沒有起到輔助設計和減少缺陷的作用，同時還導致代碼更加難以維護。
    基于這個想法，作者畫了一張圖來表示：

      作者認為，
            （1）代碼本身很復雜但是對外部的依賴很少（左上），最適合單元測試，因為耗費較少和收益較多。一般來說，某種算法（排序），核心業務規則，數據解析類似的模塊屬于這樣的代碼
            （2）帶有很多依賴的瑣碎代碼（Trivial Code with many dependencies，右下）：稱為協調者（Coordinators），因為這些代碼主要用于集成多個代碼單元和安排代碼單元之間的交互。這些代碼不適用于單元測試，因為耗費很高，收益卻不大。
             （3）代碼很復雜而且外部依賴很多（右上）：過于復雜的代碼，需要重構。
             （4）外部依賴較少的瑣碎代碼（左下）：這些代碼可測可不測，因為重要性不高，復雜度也不高，加單元測試的意義不是很大。

         對于作者的這個想法，我比較同意。正如我在2.2.4和2.2.5中提到的，對于一個在線系統（web-based application）來說，可以分為內外兩個圈：內圈由核心領域對象（Core Domain Object）構成，外圈由大量鏈接匯編代碼構成。所謂核心領域對象，這些對象包含核心業務邏輯，數目相對較少，邏輯相對比較復雜，接口（API）相對比較穩定，輸入輸出相對比較清晰，屬于算法類代碼，最合適單元測試，也需要單元測試來提高相應的質量。同時我想強調一下：這些對象一定要精心設計，精挑細選，一定要滿足數量少，接口穩定，輸入輸出清晰這三個要求。數量少意味著需要測的代碼少，相應的單元測試數量也少。接口穩定意味著用戶界面的變化（或需求變化）對單元測試的影響較小。輸入輸出清晰意味著容易驗證邏輯的正確性。相對的，外圈的代碼主要用來鏈接多個領域對象，安排他們之間的交互，轉換成用戶界面需要的數據結構。也就意味著外圈代碼和需求緊密相連，微小的用戶界面變化將會導致相應的代碼代碼，寫單元測試得不償失。

    3.3 單元測試最佳實踐和測試驅動開發反模式
    參考http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/
    （1）單元測試之間應該完全獨立的
          不要寫不必要的斷言，每次只測一個代碼單元，模擬（Mock）外部依賴，避免不必要的前提條件。
    （2）單元測試應該運行得很快（比如說少于5 min）
         單元測試需要運行得很快，這樣程序員才愿意經常運行單元測試。這就意味著（1）單元測試不要訪問數據庫（2）單元測試不要訪問網絡（3）外部依賴需要被模擬（mock）
    （3）給單元測試一個清晰和一致的命名
          一個單元測試的名字應該包含3項內容：待測對象_待測案例_期望結果，比如說ProductPurchaseAction_IfStockIsZero_RendersOutOfStockView()。 
    （4）常見的TDD反模式
           撒謊者：所有測試案例都通過了，看上去是有效的。但如果靠近看，你會發現這些案例完全沒有測試預期的內容
           過度配置：一個單元測試需要一堆配置然后才能開始測試。有的時候需要幾百行代碼配置環境，設計數十個對象。
           巨人：一個單元測試需要測試數千行代碼，并且包含大量的測試用例。
          無用者 ：有的時候模擬是有效的方便的。但是其他一些時候，過多的模擬對象，Stub對象，假對象，導致單元測試主要在測模擬對象而不是實際的系統。
          檢察官：單元測試對待測代碼非常了解，任何對待測代碼的變化將影響單元測試代碼。
          慷慨的富有者：多個單元測試共享測試數據，任何一個單元測試改動了一些數據，其他的測試全部失敗了。
          本地英雄：單元測試依賴于開發環境某些特定的配置。這意味著：在其他環境上運行單元測試將會失敗。
          采集者：單元測試驗證所有的輸出盡管它只對某些數據感興趣。
          狗仔隊：單元測試依賴于特定的實現細節，比如說，單元測試捕獲待測代碼中拋出的每一個異常。
          欺瞞者：單元測試驗證了一大堆無關的細節，但從不測試核心行為。比如說，待測代碼訪問數據庫并返回數據，單元測試驗證每個返回的數據。
          大聲說話的人：單元測試輸出一大堆診斷信息，日志信息，然而沒有清晰的成功/失敗標志。
         please refer to http://tdd-antipatterns.net/index.php?title=Main_Page     

4. 結論（前途在哪里）
        現在，我想答案應該比較清楚了。
       第一，重新強調單元測試和測試驅動開發的目地：通過寫單元測試來澄清接口（幫助系統設計），確保核心代碼（i.e.Domain Object）的正確性。它不是一個檢測缺陷的有效工具，也不應該只用覆蓋率來衡量單元測試的質量
       第二，只對核心代碼（比如說主要業務對象）進行單元測試。待測對象需要有相對有限的API數量，比較穩定的接口定義和清晰的輸入輸出。不要把寶貴的時間花在測試大量的非核心代碼，比如說，鏈接（多個核心對象），協調（多個核心對象），和需求/用戶接口緊密相關的代碼。
       第三，不要濫用單元測試，請時刻關注最佳實踐和TDD反模式。
       第四，好的單元測試來源于好的設計。設計不好，代碼不會好，單元測試也不會好。
       最后，我還想繼續研究行為驅動開發（BDD），看看BDD是否更實用，請繼續關注。