軟體開發離不開測試，而與開發人員關係最密切的當屬單元測試了。別看單元測試只是整個軟體測試學科的一部分，但是他裡面的學問也不少，今天就跟大家分享一下，單元測試的七種境界。
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倍或者更多。
七種境界，層層遞進、層層深入，從形式主義到將單元測試真正的應用到工作中，這也是我們從一開始接觸單元測試，到慢慢熟悉、到深入理解、到靈活運用的一個自然過程。你們現在都處在哪個階段呢？請自己找位置坐吧~~