菜鳥要作架構師（三）——單元測試的七種境界

軟件開發離不開測試，而與開發人員關係最密切的當屬單元測試了。別看單元測試只是整個軟件測試學科的一部分，可是他裏面的學問也很多，今天就跟你們分享一下，單元測試的七種境界。

1，以各類藉口拒絕單元測試Unit Test，比較經常使用的是「你沒有足夠的時間（進行單元測試）」。

不管是對單元測試的老手仍是新手編寫單元測試仍是有必定得工做量的，並且單元測試也須要掌握大量的測試框架和工具（光一個junit或testng你很難工做地很happy）。因此在這個階段開發人員每每會以爲單元測試很難寫、很費時，天然而然會使用沒有足夠的時間（進行單元測試）的藉口，其實在這個階段開發人員須要積極地學習和掌握測試框架和理解單元測試理念。

2，嘗試單元測試而且馬上開始在本身的博客商鼓吹單元測試和測試驅動開發Test Driven Development的好處。

開發人員在這個階段學習很掌握了一些單元測試的工具並在實際工做中加以的運用，並很好的解決了一些問題，意識到了單元測試的價值。我本身也向同事和同窗介紹過相關的技術，但願你們對相關的技術能很好的學習和運用，如今回想那個時候對單元測試的技術的掌握和理解都是不完整的，只能說是初窺門徑而已。

3，單元測試一切。爲了可以完成單元測試，而將私有private的方法和屬性修改成內部internal；爲了達到單元測試覆蓋率100%而測試getter() 和 setter() 屬性（方法）。

這樣的階段很明顯，特別是遇到private，static方法的測試時會感到很麻煩，因此每每採用了一些不優美的解決方式，目的是可以對相關的方法和類進行單元測試，但沒有從根本上意識到是本身的設計有問題，從而致使可測試比較差（testability）。至於對getter和setter方法進行測試到是沒有過，可能只本身所在的公司一直都沒有片面的強調過測試100%覆蓋率吧。

4，沒法忍受脆弱的單元測試，在沒有弄明白是什麼的時候，就匆忙轉向「集成測試"。

單元測試也是代碼，只要是代碼就會有設計、編碼上共同的問題，好比設計模式的運用、重複代碼的問題。在沒法理解和單元測試中「單元」和「隔離」這兩個名詞的狀況下，會想要經過集成測試來實現單元測試。我本身沒有運用過集成測試的工具，但用dbunit直接模擬數據庫的狀況，從而將多個類「集成」起來測試是這個階段最經常使用的單元測試方法。實際上用dbunit直接模擬數據庫也是很是脆弱和繁瑣的，mocking纔是王道。

5，發現了一種模擬 mocking 框架，而且樂於使用強制語義（strict semantics）。

mocking是單元測試中不可缺乏的重要組成，Java的單元測試方案中Easymock和Jmock是兩個成熟的Mock框架。但Mocking的學習和理解多是單元測試工具中最具備難度的地方了，經過運用Mocking你會發覺以前不少工做（好比數據庫模擬）都是浪費時間、精力和無效的。

6，模擬mock全部可能模擬mocked的對象。

經過在單元測試中運用Mocking真正貫徹了單元測試的「單元」和「隔離」的原則，不過Mocking是在件繁瑣和困難的事情，這時候就須要考慮什麼是必需要mock的、什麼能夠不mock的。

7，開始真正有效單元測試。

恭喜你終於達到了這個階段，你已經將面向對象設計、設計模式、單元測試、重構等一些技術都融匯到了一塊兒，你終於能夠根據本身的意願編寫真正有效的單元測試了。在這個階段可能你掌握或有了一套測試框架，這套測試框架整合了junit、testng、jmock、easymock、dbunit、xumlunit、unitils等一系列你測試工具使你的編寫單元測試效率是以前的3-4倍或者更多。

七種境界，層層遞進、層層深刻，從形式主義到將單元測試真正的應用到工做中，這也是咱們從一開始接觸單元測試，到慢慢熟悉、到深刻理解、到靈活運用的一個天然過程。大家如今都處在哪一個階段呢？請本身找位置坐吧~~