单元测试的7种境界
1. 以各種借口拒絕單元測試Unit Test,比較常用的是“你沒有足夠的時間(進(jìn)行單元測試)”。
無論是對單元測試的老手還是新手編寫單元測試還是有一定得工作量的,而且單元測試也需要掌握大量的測試框架和工具(光一個junit或testng你很難工作地很happy)。所以在這個階段開發(fā)人員往往會覺得單元測試很難寫、很費(fèi)時,自然而然會使用沒有足夠的時間(進(jìn)行單元測試)的借口,其實在這個階段開發(fā)人員需要積極地學(xué)習(xí)和掌握測試框架和理解單元測試?yán)砟睢?br />
2. 嘗試單元測試并且立刻開始在自己的博客商鼓吹單元測試和測試驅(qū)動開發(fā)Test Driven Development的好處。
開發(fā)人員在這個階段學(xué)習(xí)很掌握了一些單元測試的工具并在實際工作中加以的運(yùn)用,并很好的解決了一些問題,意識到了單元測試的價值。我自己也向同事和同學(xué)介紹過相關(guān)的技術(shù),希望大家對相關(guān)的技術(shù)能很好的學(xué)習(xí)和運(yùn)用,現(xiàn)在回想那個時候?qū)卧獪y試的技術(shù)的掌握和理解都是不完整的,只能說是初窺門徑而已。
3. 單元測試一切。為了能夠完成單元測試,而將私有private的方法和屬性修改為內(nèi)部internal;為了達(dá)到單元測試覆蓋率100%而測試getter() 和 setter() 屬性(方法)。
這樣的階段很明顯,特別是遇到private,static方法的測試時會感到很麻煩,所以往往采用了一些不優(yōu)美的解決方式,目的是能夠?qū)ο嚓P(guān)的方法和類進(jìn)行單元測試,但沒有從根本上意識到是自己的設(shè)計有問題,從而導(dǎo)致可測試比較差(testability)。至于對getter和setter 方法進(jìn)行測試到是沒有過,可能只自己所在的公司一直都沒有片面的強(qiáng)調(diào)過測試100%覆蓋率吧。
4. 無法忍受脆弱的單元測試,在沒有弄明白是什么的時候,就匆忙轉(zhuǎn)向“集成測試"。
單元測試也是代碼,只要是代碼就會有設(shè)計、編碼上共同的問題,比如設(shè)計模式的運(yùn)用、重復(fù)代碼的問題。在無法理解和單元測試中“單元”和“隔離”這兩個名詞的情況下,會想要通過集成測試來實現(xiàn)單元測試。我自己沒有運(yùn)用過集成測試的工具,但用dbunit直接模擬數(shù)據(jù)庫的情況,從而將多個類“集成”起來測試是這個階段最常用的單元測試方法。實際上用dbunit直接模擬數(shù)據(jù)庫也是非常脆弱和繁瑣的,mocking才是王道。
5. 發(fā)現(xiàn)了一種模擬 mocking 框架,并且樂于使用強(qiáng)制語義(strict semantics)。
mocking是單元測試中不可缺少的重要組成,Java的單元測試方案中Easymock和Jmock是兩個成熟的Mock框架。但 Mocking的學(xué)習(xí)和理解可能是單元測試工具中最具有難度的地方了,通過運(yùn)用Mocking你會發(fā)覺之前很多工作(比如數(shù)據(jù)庫模擬)都是浪費(fèi)時間、精力和無效的。
6. 模擬mock所有可能模擬mocked的對象。
通過在單元測試中運(yùn)用Mocking真正貫徹了單元測試的“單元”和“隔離”的原則,不過Mocking是在件繁瑣和困難的事情,這時候就需要考慮什么是必須要mock的、什么可以不mock的。
7. 開始真正有效單元測試。
恭喜你終于達(dá)到了這個階段,你已經(jīng)將面向?qū)ο笤O(shè)計、設(shè)計模式、單元測試、重構(gòu)等一些技術(shù)都融匯到了一起,你終于可以根據(jù)自己的意愿編寫真正有效的單元測試了。在這個階段可能你掌握或有了一套測試框架,這套測試框架整合了junit、testng、jmock、easymock、dbunit、xumlunit、unitils等一系列你測試工具使你的編寫單元測試效率是之前的3-4倍或者更多
轉(zhuǎn)載于:https://www.cnblogs.com/xmax130/p/4080204.html
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯,堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結(jié)
- 上一篇: CUDA编程注意
- 下一篇: 探针台常见问题—如何减少LHe制冷剂消耗