最近遇到一個單元測試的問題，本周正好學(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)計算工程中的實體，自動去完成序列化與反序列化。
