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