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倍或者更多

轉載于:https://www.cnblogs.com/xmax130/p/4080204.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的单元测试的7种境界的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。