作為一名程序員,單元測試應(yīng)該聽過,但是很多同學(xué)沒有用的過,可能是對單元測試有一些誤解,例如:
- 寫單元測試需要花費(fèi)更多的時(shí)間,我每天寫產(chǎn)品代碼都要加班,哪來時(shí)間寫測試;
- 寫單元測試收益不大,還不是一樣有bug;
- 寫單元測試有負(fù)擔(dān),改產(chǎn)品代碼的結(jié)構(gòu),還得去改測試代碼。
先嘗試解答這幾個(gè)問題。
寫單元測試會花費(fèi)更多的時(shí)間,這點(diǎn)描述其實(shí)不準(zhǔn)確。準(zhǔn)確地說,寫單元測試需要花費(fèi)更多「寫代碼的時(shí)間」,這點(diǎn)沒什么可說的,畢竟要多寫一些測試代碼。但一個(gè)程序員,做一個(gè)需求的時(shí)候,花在純寫代碼的時(shí)間其實(shí)不多。你得理以前代碼的邏輯,設(shè)計(jì)類和方法,然后才是寫代碼,寫完了再手動測試,可能有bug
還要去debug
,再修復(fù),再測試?!?strong>真正寫代碼的時(shí)間,其實(shí)是很少的」。使用單元測試雖然可能占用了更多寫代碼的時(shí)間,但它可以幫你縮短其它時(shí)間,「會讓你做這個(gè)需求花費(fèi)的總時(shí)間更少」。
寫單元測試會有bug
嗎?當(dāng)然可能有了,我們是無法做到真正的bug free
的,但是單元測試寫好了,可以顯著減小bug
的數(shù)量。因?yàn)閷憜卧獪y試發(fā)現(xiàn)bug
的成本是非常低的,它可以在開發(fā)階段就發(fā)現(xiàn)bug
,而且可以測試很多邊界的條件。但如果你「對需求和業(yè)務(wù)的認(rèn)知本來都是有誤」的,這是單元測試解決不了的,自然會產(chǎn)生bug
。話說回來,寫單元測試的收益遠(yuǎn)不止發(fā)現(xiàn)bug
這么簡單,它還具有「代碼文檔」的功能,以及「重構(gòu)的安全網(wǎng)」存在。甚至它還可以幫你「理需求」,「設(shè)計(jì)代碼」。
改產(chǎn)品代碼需要維護(hù)對應(yīng)的測試代碼,這確實(shí)是帶來了額外的成本。不過借助編輯器的「重構(gòu)功能」,可以比較方便地批量修改需要修改的地方,其實(shí)代價(jià)沒有想象中的那么大。而且重構(gòu)后,再跑一遍單元測試,看哪些掛掉了,可以double-check
你改的產(chǎn)品代碼有沒有問題。如果我們把單元測試當(dāng)成是「產(chǎn)品代碼的文檔」來看,大概就更能夠接受這個(gè)維護(hù)的成本了。
為什么需要單元測試?
前面提到,單元測試有很多功能。個(gè)人覺得單元測試最大的作用是“代碼文檔”和“重構(gòu)安全網(wǎng)”。畢竟軟件開發(fā)的漫長過程中,總少不了修修改改。如果沒有足夠的測試,改一段代碼就像是在排地雷,改完后心里也總是打鼓,上線前需要先默默拜個(gè)神,生怕觸發(fā)了什么bug
。
但如果有足夠的測試(不只是單元測試),改完代碼后可以跑一遍測試,看哪些掛掉了,是不是自己的改動導(dǎo)致的,該怎么修好測試。這樣心里就有底氣多了。
要知道,代碼寫出來是給人看的。而測試比產(chǎn)品代碼更友好,因?yàn)樗唵危卑?,站在使用者的視角來描述,所以如果想要了解一段產(chǎn)品代碼具有什么功能,看它的單元測試會更直觀,更舒服。
很多團(tuán)隊(duì)會做測試,但絕大多數(shù)測試的工作是在開發(fā)后,由專門的測試同學(xué)去負(fù)責(zé)端到端的測試或者API
測試。其實(shí)端到端的測試成本是非常大的,尤其是對于某些邊界條件,構(gòu)造數(shù)據(jù)和場景是非常麻煩的。而且一旦發(fā)現(xiàn)了bug
,再去溝通,修改,提交,部署,需要花費(fèi)很多時(shí)間。
而單元測試最大的優(yōu)勢就是“成本低”,想要測試產(chǎn)品代碼的每個(gè)分支都比較容易,而且單元測試一般是開發(fā)同學(xué)自己寫,可以用最小的時(shí)間發(fā)現(xiàn)bug
,用最低的成本修改bug
。
什么是單元測試?
測試金字塔
并不是所有測試都是單元測試,測試其實(shí)分成很多種。業(yè)界比較廣泛傳播的“測試金字塔”描述了它們的區(qū)別和關(guān)系:
從測試金字塔模型來看,越在底層的測試,覆蓋面應(yīng)該更廣,成本更低。單元測試處于測試金字塔的最低端,是整個(gè)測試金字塔的基礎(chǔ)。
當(dāng)然了,測試金字塔并不一定只有三層,中間可能會有其它的測試,比如“契約測試”等。
單元測試的特點(diǎn)
單元測試就像它的名字一樣,“單元”(Unit),足夠小,足夠快,無依賴。單元測試只測你想測的那部分產(chǎn)品代碼的邏輯,一個(gè)單元測試應(yīng)該只測一個(gè)簡單的業(yè)務(wù)邏輯。一般來說,運(yùn)行一個(gè)單元測試是很快的,基本上在幾毫秒到幾十毫秒之間。如果有依賴的類,可以mock
其他類,消除外部依賴。
什么不是單元測試?
很多同學(xué)容易將其他測試與單元測試搞混,最常見的是會啟動Spring
上下文的集成測試。比如使用@SpringBootTest
注解可以啟動Spring
上下文,這可以測試依賴是否正常注入等Spring
的功能,但運(yùn)行一次需要耗費(fèi)很多時(shí)間(因?yàn)橐獑覵pring上下文),也并不是真正的“單元測試”,因?yàn)樗蕾嚵?code>Spring框架。
如何寫單元測試
那具體如何寫單元測試呢?我們業(yè)界有一個(gè)叫做「TDD」(測試驅(qū)動開發(fā))的方法論。TDD
的核心在于“驅(qū)動”二字,它的理念是從測試視角出發(fā),通過測試驅(qū)動出來產(chǎn)品代碼。而在測試金字塔中,單元測試與開發(fā)人員最息息相關(guān),所以這里的“測試”一般是指的單元測試。
TDD大概分這幾個(gè)步驟:
- 理清需求
- 設(shè)計(jì)類和方法的出參和入?yún)?/li>
- 寫測試代碼
- 驅(qū)動出產(chǎn)品代碼
- 重構(gòu),循環(huán)3-5步。
首先要理清楚需求,因?yàn)橹挥欣砬宄诵枨?,才能保證我們使用TDD
驅(qū)動出來的代碼是跟業(yè)務(wù)期望的一致的。然后第二步是設(shè)計(jì)類和方法的過程,也稱為Task List
。這一步可以設(shè)計(jì)好類與類之間的關(guān)系,方法的出參和入?yún)?。其?shí)不使用TDD
也會有前面這兩個(gè)步驟,只不過使用TDD
的話,可以幫助你更好地從業(yè)務(wù)視角出發(fā),先把該設(shè)計(jì)的東西都設(shè)計(jì)好,避免直接上手寫代碼,寫到一半的時(shí)候覺得不對,再去改。
3-5步其實(shí)是一個(gè)循環(huán)的過程。因?yàn)閯傞_始寫代碼可能并沒有太注意代碼的格式、風(fēng)格、性能,一氣呵成寫得比較快,讓測試通過。等測試通過后,可以回過頭來重構(gòu)一下之前寫的代碼,重構(gòu)后再跑一遍所有的單元測試,看是否有掛掉的單元測試,以此來檢測重構(gòu)是否對期望的輸入輸出有影響。
單元測試的結(jié)構(gòu)
一個(gè)完整的單元測試,應(yīng)該分為4個(gè)部分:
- 聲明和參數(shù)
- 準(zhǔn)備入?yún)⒑蚼ock
- 調(diào)用產(chǎn)品代碼
- 驗(yàn)證,也叫斷言
拿Java
來說,單元測試框架有幾個(gè),最流行的應(yīng)該是JUnit
和TestNG
。筆者使用JUnit
多一點(diǎn),JUnit
使用@Test
注解在方法上來聲明一個(gè)測試。JUnit
最新版本是JUnit 5
,JUnit 5
相較于上一個(gè)版本,在參數(shù)化測試方面做了很多改進(jìn),這樣我們就不用寫很多個(gè)高度相似的測試方法了(關(guān)于JUnit 5參數(shù)化測試,大家可以查看官方文檔,也有對應(yīng)的中文翻譯,很方便閱讀)。
一般來說,方法名需要盡可能可讀,它可能比較長,但能夠清晰地表述這個(gè)測試的意圖,比如:
@Test void shouldReturn5WhenCalculateSumGiven2And3() {}
@Test
void should_return_5_when_calculate_sum_given_2_and_3() {}
具體使用駝峰命名法還是下劃線,根據(jù)自己團(tuán)隊(duì)的規(guī)范來就好,盡量所有測試風(fēng)格保持一致。(個(gè)人更喜歡下劃線~)
入?yún)⒁话闶腔绢愋突蛘?code>POJO對象,有些參數(shù)可以抽成變量,后面在驗(yàn)證階段可能用得上。
如果產(chǎn)品代碼有外部依賴,就需要用mock
來消除外部依賴。常見的Mock
框架有EasyMock
、「Mockito」等,大家可以對比一下各個(gè)mock
框架的區(qū)別,選擇一個(gè)合適的。
很多同學(xué)剛開始寫單元測試的時(shí)候不能理解為什么需要mock
,覺得mock
比較麻煩,甚至有點(diǎn)多此一舉的感覺。其實(shí)不然,mock
的意義在于,你「可以保證你的測試只測試了你要測的那部分代碼」。這樣如果測試不通過,你就可以知道一定是要測的那個(gè)方法有問題,不可能是外部依賴的問題,這樣才能做到真正的“單元”化,才能保證每個(gè)測試足夠小,足夠純粹。
準(zhǔn)備好入?yún)⒑?code>mock后,會顯式地調(diào)用一下要測的那個(gè)方法,這個(gè)一般只有簡單的一行。
最后是驗(yàn)證,驗(yàn)證分為好幾種,最常用的是驗(yàn)證出參是符合自己期望的。也有時(shí)候會驗(yàn)證異常等邊界情況。JUnit
等測試框架基本上自己帶了驗(yàn)證的功能,但API
都比較簡單,個(gè)人感覺不是特別好用,推薦使用「AssertJ」,功能強(qiáng)大,API
用起來也比較舒服。
舉個(gè)例子吧:
@Test void shouldReturnUserWithOrgInfoWhenLoginWithUserId() { String userId = "userId"; String orgId = "orgId"; User user = UserFactory.getUser(userId); Org org = OrgFactory.getOrg(orgId); given(orgService.getOrgById(orgId)).willReturn(org);
UserInfo userInfo = userService.login(userId);
assertEquals(org, userInfo.getOrg());
}
單元測試常見問題
下面聊一聊單元測試常見的一些問題。
先寫測試還是先寫產(chǎn)品代碼?
都可以。雖然有一種說法是TDD
推薦的是先寫測試,再寫實(shí)現(xiàn)。但很多剛開始寫單元測試的同學(xué)并不習(xí)慣這種方式。先寫測試有一個(gè)好處,可以讓你在設(shè)計(jì)代碼的時(shí)候從業(yè)務(wù)視角去思考,而不是代碼實(shí)現(xiàn)視角。大家可以嘗試先寫測試再寫實(shí)現(xiàn),體會一下這種感覺。
寫單元測試需要花費(fèi)大量額外的時(shí)間?
這個(gè)其實(shí)在文章開篇已經(jīng)討論過了。寫單元測試確實(shí)會花費(fèi)更多的“寫代碼”的時(shí)間,但是總的來說,它可以縮短整個(gè)需求開發(fā)周期的時(shí)間。所以寫單元測試完全是一筆“劃算的生意”。
什么代碼最需要單元測試?
不自信的代碼,邏輯復(fù)雜的代碼,重要的代碼。比如工具類、三層架構(gòu)的Service
層、DDD
的聚合根和領(lǐng)域服務(wù)等,這些都應(yīng)該寫足夠的單元測試。
入?yún)ο髽?gòu)造太麻煩?
構(gòu)造一個(gè)合適的入?yún)ο蟊容^麻煩,尤其是有些對象有非常多的參數(shù),如果每個(gè)測試都要去從頭構(gòu)造的話,會讓測試代碼變得非常臃腫,可讀性變差。這個(gè)時(shí)候可以使用工廠類來批量生產(chǎn)對象。這個(gè)工廠類放在測試目錄下,并不會對生產(chǎn)代碼造成影響。前面的例子里面,UserFactory
就是一個(gè)User
對象的工廠類。
返回值為void測什么?
返回值為void
,說明方法沒有出參,那方法內(nèi)部必然有一些行為,它可能是「改變了內(nèi)部屬性的值」,也可能是「調(diào)用了某個(gè)外部類的方法」。
如果是改變內(nèi)部的某個(gè)值,那可以通過對象的get
參數(shù)來斷言。這在使用DDD
后的領(lǐng)域模型是一個(gè)問題,因?yàn)橛锌赡鼙緛懋a(chǎn)品代碼不需要暴露出get
方法的,但由于測試需要,暴露出了內(nèi)部屬性的get
方法。雖然使用反射也可以拿到內(nèi)部屬性的值,但沒有太大必要。權(quán)衡利弊,還是暴露領(lǐng)域模型的get
方法好一點(diǎn)。
如果是調(diào)用某個(gè)外部的方法,可以用verify
來驗(yàn)證是否調(diào)用了某個(gè)方法,可以用capture
驗(yàn)證調(diào)用其它方法的入?yún)ⅰ_@樣也可以驗(yàn)證產(chǎn)品代碼是否如自己預(yù)期的設(shè)計(jì)在工作。
static方法如何mock?
static
方法不好mock
,需要用特殊的mock
框架。比如PowerMock
、JMockit
。一般來說,Utils
類的方法很多是static
的,我們用得很多的時(shí)間類LocalDateTime
,獲取當(dāng)前時(shí)間,也是static
的。這個(gè)時(shí)候需要用專門的mock
框架來mock
一下。
多線程如何測試?
多線程也不好測試。如果程序簡單,可以用「睡眠」或者CountDownLatch
等多線程工具類來輔助測試,等所有線程跑完,再統(tǒng)一驗(yàn)證。
如果程序相對復(fù)雜,需要使用專門的多線程測試框架,比如tempus-fugit
、Thread Weaver
、MultithreadedTC
、以及OpenJDK
的jcstress
項(xiàng)目等。
關(guān)于具體的框架如何使用,以后有時(shí)間可以寫一篇常用的注解的介紹。其實(shí)官方文檔里面都有寫,大家照著官網(wǎng)寫幾個(gè)例子就會了。比較推薦的基礎(chǔ)套餐是junit 5 + mockito + assertj
。關(guān)于static
方法和多線程測試框架,大家有需要的時(shí)候再去了解也行。
想了解更多測試的看一下相關(guān)教程:
軟件測試:http://m.hgci.cn/software_testing/
文章參考來源:www.toutiao.com/a6856755990545891848/