最近遇到一個(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)去完成序列化與反序列化。
