最近遇到一個單元測試的問題,本周正好學(xué)個了一個SCORE法則,這里正好練練手應(yīng)用此法則將問題的前因后果分享給大家。
S:背景
代碼要有單元測試,檢測的標(biāo)準(zhǔn)就是統(tǒng)計代碼的單元測試覆蓋率,程序員需要達(dá)到指定的最低覆蓋率要求。
C:沖突,或者叫問題吧
項目結(jié)構(gòu)與代碼掃描工具的特殊關(guān)系導(dǎo)致需要額外寫更多的單元測試,因為目前開發(fā)管理部門的代碼描述配置的是按JAVA工程來掃描,并不能將多個工程當(dāng)成一個整體來掃描。
我的一個項目將接口以及實體對象單獨(dú)成立為一個JAVA工程,整個項目分成兩個JAVA工程:
接口以及實體,工程名稱為core
業(yè)務(wù)邏輯以及數(shù)據(jù)持久化的實現(xiàn),工程名稱為service,依賴上面的core
一般情況下,由于core里面只包含接口以及實體,所以我沒有意識到去寫單元測試,因為單元測試的價值會比較小,無非就是測試實體是否可以序列化,如果實現(xiàn)了JSR303,那么這些校驗的邏輯可能也有點(diǎn)測試的價值。由于我們的service依賴core,在為service寫單元測試時,實際上已經(jīng)調(diào)用了接口以及實體,理論上是不需要再為core去寫單元測試的。但核心問題時代碼掃描工具目前開發(fā)管理部門做的還沒這么智能,它是以單個JAVA工程來統(tǒng)計單元測試覆蓋率的,針對我們的結(jié)構(gòu)如果只在service中寫單元測試,那么有效的代碼覆蓋行只會統(tǒng)計service項目中的,至于調(diào)用的core項目中的代碼并不包含在其中。而core的這些接口以及實體所占的代碼行還是有一定分量的,如果不將這些統(tǒng)計進(jìn)來那么想達(dá)到高的覆蓋率還是比較費(fèi)勁的,除非你有大把的時間去寫。
O:選擇的方案
實體對象無非就是一些get,set成本的方法,要想測試它們我們可以利用序列化機(jī)制,對象序列化成字符串會完成get調(diào)用,反過來將字符串序列化成對象會完成set的調(diào)用,那如何實現(xiàn)呢?
為每個實體對象,編寫單元測試,實例化對象,最后完成序列化與反序列化。
優(yōu)點(diǎn):可以精確的控制每個屬性的值
缺點(diǎn):需要編寫眾多單元測試,時間成本高,且新增加實體類就意味著要編寫新的單元測試,刪除或者修改也會影響。
利用反射機(jī)制,動態(tài)計算工程中的實體,自動去完成序列化與反序列化。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26