其實(shí)之前的工作中強(qiáng)調(diào)過(guò)很多次自己做測(cè)試的重要性，例如講單元測(cè)試的：【C#編程最佳實(shí)踐 一】單元測(cè)試實(shí)踐，講單元測(cè)試規(guī)范的【阿里巴巴Java編程規(guī)范學(xué)習(xí) 四】Java質(zhì)量安全規(guī)約，講接口測(cè)試的：【C#編程最佳實(shí)踐 十三】接口測(cè)試實(shí)踐，這里舊事重提就不再詳細(xì)展開(kāi)了，回顧下單元測(cè)試的基本概念，重點(diǎn)來(lái)看如何提升代碼的可測(cè)試性。
單元測(cè)試
依次從WHAT，WHY，HOW，HOW去了解。
什么是單元測(cè)試
單元測(cè)試由RD自己來(lái)編寫，用來(lái)測(cè)試自己寫的代碼的正確性。它與集成測(cè)試的區(qū)別是測(cè)試粒度
- 集成測(cè)試的測(cè)試對(duì)象是整個(gè)系統(tǒng)或者某個(gè)功能模塊，比如測(cè)試用戶注冊(cè)、登錄功能是否正常，是一種端到端（end to end）的測(cè)試。
- 單元測(cè)試的測(cè)試對(duì)象是類或者函數(shù)，用來(lái)測(cè)試一個(gè)類和函數(shù)是否都按照預(yù)期的邏輯執(zhí)行。這是代碼層級(jí)的測(cè)試
單元測(cè)試相對(duì)于集成測(cè)試（Integration Testing）來(lái)說(shuō)，測(cè)試的粒度更小一些。
寫單元測(cè)試的好處
單元測(cè)試除了能有效地為重構(gòu)保駕護(hù)航之外，也是保證代碼質(zhì)量最有效的兩個(gè)手段之一（另一個(gè)是 Code Review），寫單元測(cè)試有如下好處：
- 寫單元測(cè)試能有效地發(fā)現(xiàn)代碼中的 bug，通過(guò)寫單元測(cè)試可以節(jié)省很多 fix 低級(jí) bug 的時(shí)間，能夠有時(shí)間去做其他更有意義的事情。
- 寫單元測(cè)試能發(fā)現(xiàn)代碼設(shè)計(jì)上的問(wèn)題，代碼的可測(cè)試性是評(píng)判代碼質(zhì)量的一個(gè)重要標(biāo)準(zhǔn)。對(duì)于一段代碼，如果很難為其編寫單元測(cè)試，或者單元測(cè)試寫起來(lái)很吃力，需要依靠單元測(cè)試框架里很高級(jí)的特性才能完成，那往往就意味著代碼設(shè)計(jì)得不夠合理，比如，沒(méi)有使用依賴注入、大量使用靜態(tài)函數(shù)、全局變量、代碼高度耦合等
- 單元測(cè)試是對(duì)集成測(cè)試的有力補(bǔ)充，程序運(yùn)行的 bug 往往出現(xiàn)在一些邊界條件、異常情況下，比如，除數(shù)未判空、網(wǎng)絡(luò)超時(shí)。而大部分異常情況都比較難在測(cè)試環(huán)境中模擬
- 寫單元測(cè)試的過(guò)程本身就是代碼重構(gòu)的過(guò)程，持續(xù)重構(gòu)應(yīng)該作為開(kāi)發(fā)的一部分來(lái)執(zhí)行，寫單元測(cè)試實(shí)際上就是落地執(zhí)行持續(xù)重構(gòu)的一個(gè)有效途徑。設(shè)計(jì)和實(shí)現(xiàn)代碼的時(shí)候，我們很難把所有的問(wèn)題都想清楚編寫單元測(cè)試就相當(dāng)于對(duì)代碼的一次自我 Code Review，在這個(gè)過(guò)程中，可以發(fā)現(xiàn)一些設(shè)計(jì)上的問(wèn)題（比如代碼設(shè)計(jì)的不可測(cè)試）以及代碼編寫方面的問(wèn)題（比如一些邊界條件處理不當(dāng)）等，然后針對(duì)性的進(jìn)行重構(gòu)
- 閱讀單元測(cè)試能幫助我們快速熟悉代碼，文檔結(jié)合單元測(cè)試，我們不需要深入的閱讀代碼，便能知道代碼實(shí)現(xiàn)了什么功能，有哪些特殊情況需要考慮，有哪些邊界條件需要處理。不需要深入的閱讀代碼，便能知道代碼實(shí)現(xiàn)了什么功能，有哪些特殊情況需要考慮，有哪些邊界條件需要處理。
- 單元測(cè)試是 TDD 可落地執(zhí)行的改進(jìn)方案，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-Driven Development，簡(jiǎn)稱 TDD）是一個(gè)經(jīng)常被提及但很少被執(zhí)行的開(kāi)發(fā)模式。它的核心指導(dǎo)思想就是測(cè)試用例先于代碼編寫，但很難落地，不如先寫代碼，緊接著寫單元測(cè)試，最后根據(jù)單元測(cè)試反饋出來(lái)問(wèn)題，再回過(guò)頭去重構(gòu)代碼，變相落實(shí)TDD，測(cè)試驅(qū)動(dòng)重構(gòu)與FIX
其實(shí)單元測(cè)試就是對(duì)代碼設(shè)計(jì)和功能邏輯的一次反思，粗粒度的CR，結(jié)合CR，推動(dòng)和保障持續(xù)重構(gòu)。
如何編寫單元測(cè)試
物理上可以借助Java 中比較出名的單元測(cè)試框架有 Junit、TestNG、Spring Test 等。這些框架提供了通用的執(zhí)行流程（比如執(zhí)行測(cè)試用例的 TestCaseRunner）和工具類庫(kù)（比如各種 Assert 判斷函數(shù)），而主觀經(jīng)驗(yàn)上要有這樣的意識(shí)
- 編寫單元測(cè)試盡管繁瑣，但并不是太耗時(shí)，不同測(cè)試用例之間的代碼差別可能并不是很大，簡(jiǎn)單 copy-paste 改改就行
- 可以稍微放低對(duì)單元測(cè)試代碼質(zhì)量的要求，命名稍微有些不規(guī)范，代碼稍微有些重復(fù)，也都是沒(méi)有問(wèn)題的，但代碼規(guī)范意識(shí)要時(shí)刻有，要達(dá)到想降低要求都降不了的水平
- 覆蓋率作為衡量單元測(cè)試質(zhì)量的重要但不是唯一標(biāo)準(zhǔn)，更重要的是要看測(cè)試用例是否覆蓋了所有可能的情況
- 單元測(cè)試不要依賴被測(cè)試函數(shù)的具體實(shí)現(xiàn)邏輯，它只關(guān)心被測(cè)函數(shù)實(shí)現(xiàn)了什么功能。切不可為了追求覆蓋率，逐行閱讀代碼
- 通過(guò)單元測(cè)試框架無(wú)法測(cè)試，多半是因?yàn)榇a的可測(cè)試性不好，需要思考下代碼的設(shè)計(jì)
單元測(cè)試就是一個(gè)透明測(cè)試，我們只關(guān)注功能而無(wú)需關(guān)注實(shí)現(xiàn)細(xì)節(jié)，關(guān)注的功能要關(guān)注是否覆蓋了所有可能場(chǎng)景
單元測(cè)試為何難落地執(zhí)行
一方面，寫單元測(cè)試本身比較繁瑣，技術(shù)挑戰(zhàn)不大，很多程序員不愿意去寫；另一方面，研發(fā)比較偏向“快、糙、猛”，容易因?yàn)殚_(kāi)發(fā)進(jìn)度緊，導(dǎo)致單元測(cè)試的執(zhí)行虎頭蛇尾。最后，關(guān)鍵問(wèn)題還是團(tuán)隊(duì)沒(méi)有建立對(duì)單元測(cè)試正確的認(rèn)識(shí)，覺(jué)得可有可無(wú)，單靠督促很難執(zhí)行得很好
代碼可測(cè)試性
簡(jiǎn)而言之，代碼的可測(cè)試性，就是針對(duì)代碼編寫單元測(cè)試的難易程度。對(duì)于一段代碼，如果很難為其編寫單元測(cè)試，或者單元測(cè)試寫起來(lái)很費(fèi)勁，需要依靠單元測(cè)試框架中很高級(jí)的特性，那往往就意味著代碼設(shè)計(jì)得不夠合理，代碼的可測(cè)試性不好.
提高代碼可測(cè)試性：依賴注入和二次封裝
如何讓代碼可測(cè)試性更好呢？最常用的方式就是依賴注入了，通過(guò)DI實(shí)現(xiàn)反轉(zhuǎn)，將對(duì)象的創(chuàng)建交給業(yè)務(wù)調(diào)用方，這樣就可以隨意控制輸出的結(jié)果，從而達(dá)到mock數(shù)據(jù)的目的，最好搭配多態(tài)，讓mock類之間基于父類注入，例如將Mock數(shù)據(jù)注入到類中進(jìn)行測(cè)試。例如
public class MockWalletRpcServiceOne extends WalletRpcService {
public String moveMoney(Long id, Long fromUserId, Long toUserId, Double amount) {
return "123bac";
}
}
public class MockWalletRpcServiceTwo extends WalletRpcService {
public String moveMoney(Long id, Long fromUserId, Long toUserId, Double amount) {
return null;
}
}
通過(guò)依賴注入注入到主類
public class Transaction {
//...
// 添加一個(gè)成員變量及其set方法
private WalletRpcService walletRpcService;
public void setWalletRpcService(WalletRpcService walletRpcService) {
this.walletRpcService = walletRpcService;
}
// ...
public boolean execute() {
// ...
// 刪除下面這一行代碼
// WalletRpcService walletRpcService = new WalletRpcService();
// ...
}
}
使用時(shí)直接注入Mock類
public void testExecute() {
Long buyerId = 123L;
Long sellerId = 234L;
Long productId = 345L;
Long orderId = 456L;
Transction transaction = new Transaction(null, buyerId, sellerId, productId, orderId);
// 使用mock對(duì)象來(lái)替代真正的RPC服務(wù)
transaction.setWalletRpcService(new MockWalletRpcServiceOne()):
boolean executedResult = transaction.execute();
assertTrue(executedResult);
assertEquals(STATUS.EXECUTED, transaction.getStatus());
}
對(duì)于一些需要外部依賴的遠(yuǎn)程服務(wù)，因?yàn)槲覀儾荒苄薷倪h(yuǎn)程服務(wù)代碼，所以需要組合mock、二次封裝、依賴注入等方式解決，也就是類不直接依賴于遠(yuǎn)程類，而是依賴于封裝在遠(yuǎn)程類之上的本地方法，測(cè)試的時(shí)候mock封裝類即可。例如在遠(yuǎn)程調(diào)用的RedisDistributedLock之上封裝一層而不是直接調(diào)用
public class TransactionLock {
public boolean lock(String id) {
return RedisDistributedLock.getSingletonIntance().lockTransction(id);
}
public void unlock() {
RedisDistributedLock.getSingletonIntance().unlockTransction(id);
}
}
主類與依賴的封裝類通過(guò)依賴注入來(lái)組織
public class Transaction {
//...
private TransactionLock lock;
public void setTransactionLock(TransactionLock lock) {
this.lock = lock;
}
public boolean execute() {
//...
try {
isLocked = lock.lock();
//...
} finally {
if (isLocked) {
lock.unlock();
}
}
//...
}
}
我們?cè)跍y(cè)試時(shí)就可以直接將Mock的封裝類注入主類測(cè)試
// 二次封裝遠(yuǎn)程調(diào)用類，然后將mock的封裝類DI注入到主類中進(jìn)行測(cè)試
public void testExecute() {
Long buyerId = 123L;
Long sellerId = 234L;
Long productId = 345L;
Long orderId = 456L;
TransactionLock mockLock = new TransactionLock() {
public boolean lock(String id) {
return true;
}
public void unlock() {}
};
Transction transaction = new Transaction(null, buyerId, sellerId, productId, orderId);
transaction.setWalletRpcService(new MockWalletRpcServiceOne());
transaction.setTransactionLock(mockLock);
boolean executedResult = transaction.execute();
assertTrue(executedResult);
assertEquals(STATUS.EXECUTED, transaction.getStatus());
}
哪些代碼可測(cè)試性不好
下面整理一些影響代碼可測(cè)試性的問(wèn)題
1 未決行為
所謂的未決行為邏輯就是，代碼的輸出是隨機(jī)或者說(shuō)不確定的，比如，跟時(shí)間、隨機(jī)數(shù)有關(guān)的代碼，例如：
public class Demo {
public long caculateDelayDays(Date dueTime) {
long currentTimestamp = System.currentTimeMillis();
if (dueTime.getTime() >= currentTimestamp) {
return 0;
}
long delayTime = currentTimestamp - dueTime.getTime();
long delayDays = delayTime / 86400;
return delayDays;
}
}
這是一段計(jì)算延期時(shí)間的代碼，當(dāng)前時(shí)間一直在變，而這種變化不是通過(guò)參數(shù)傳遞進(jìn)來(lái)的，所以隨著時(shí)間的推移，單元測(cè)試的輸出結(jié)果會(huì)有不同，所以為了提高代碼可測(cè)試性，可以把currentTimestamp 這個(gè)參數(shù)當(dāng)成局部變量傳進(jìn)來(lái)：
public class Demo {
public long caculateDelayDays(Date dueTime, Date currentTime) {
if (dueTime.getTime() >= currentTime..getTime()) {
return 0;
}
long delayTime = currentTime..getTime() - dueTime.getTime();
long delayDays = delayTime / 86400;
return delayDays;
}
}
2 全局變量
全局變量是一種面向過(guò)程的編程風(fēng)格，有種種弊端。濫用全局變量也讓編寫單元測(cè)試變得困難，同一個(gè)全局變量被多個(gè)單元測(cè)試用例訪問(wèn)并設(shè)置值，會(huì)讓單元測(cè)試結(jié)果不準(zhǔn)確，例如
public class RangeLimiter {
private static AtomicInteger position = new AtomicInteger(0);
public static final int MAX_LIMIT = 5;
public static final int MIN_LIMIT = -5;
public boolean move(int delta) {
int currentPos = position.addAndGet(delta);
boolean betweenRange = (currentPos <= MAX_LIMIT) && (currentPos >= MIN_LIMIT);
return betweenRange;
}
}
public class RangeLimiterTest {
public void testMove_betweenRange() {
RangeLimiter rangeLimiter = new RangeLimiter();
assertTrue(rangeLimiter.move(1));
assertTrue(rangeLimiter.move(3));
assertTrue(rangeLimiter.move(-5));
}
public void testMove_exceedRange() {
RangeLimiter rangeLimiter = new RangeLimiter();
assertFalse(rangeLimiter.move(6));
}
}
position 是一個(gè)靜態(tài)全局變量，第一個(gè)測(cè)試用例執(zhí)行完成之后，position 的值變成了 -1；再執(zhí)行第二個(gè)測(cè)試用例的時(shí)候，position 變成了 5，move() 函數(shù)返回 true，assertFalse 語(yǔ)句判定失敗。所以，第二個(gè)測(cè)試用例運(yùn)行失敗
3 靜態(tài)方法
靜態(tài)方法跟全局變量一樣，也是一種面向過(guò)程的編程思維。在代碼中調(diào)用靜態(tài)方法，有時(shí)候會(huì)導(dǎo)致代碼不易測(cè)試。主要原因是靜態(tài)方法也很難 mock，因?yàn)殪o態(tài)方法沒(méi)有多態(tài)的特性，沒(méi)辦法使用mock方法。
4 復(fù)雜繼承
相比組合關(guān)系，繼承關(guān)系的代碼結(jié)構(gòu)更加耦合、不靈活，更加不易擴(kuò)展、不易維護(hù)。實(shí)際上，繼承關(guān)系也更加難測(cè)試。這也印證了代碼的可測(cè)試性跟代碼質(zhì)量的相關(guān)性。
如果父類需要 mock 某個(gè)依賴對(duì)象才能進(jìn)行單元測(cè)試，那所有的子類、子類的子類……在編寫單元測(cè)試的時(shí)候，都要 mock 這個(gè)依賴對(duì)象。對(duì)于層次很深（在繼承關(guān)系類圖中表現(xiàn)為縱向深度）、結(jié)構(gòu)復(fù)雜（在繼承關(guān)系類圖中表現(xiàn)為橫向廣度）的繼承關(guān)系，越底層的子類要 mock 的對(duì)象可能就會(huì)越多，這樣就會(huì)導(dǎo)致，底層子類在寫單元測(cè)試的時(shí)候，要一個(gè)一個(gè) mock 很多依賴對(duì)象，而且還需要查看父類代碼，去了解該如何 mock 這些依賴對(duì)象。
利用組合而非繼承來(lái)組織類之間的關(guān)系，類之間的結(jié)構(gòu)層次比較扁平，在編寫單元測(cè)試的時(shí)候，只需要 mock 類所組合依賴的對(duì)象即可。
5 高耦合代碼
如果一個(gè)類職責(zé)很重，需要依賴十幾個(gè)外部對(duì)象才能完成工作，代碼高度耦合，那在編寫單元測(cè)試的時(shí)候，可能需要 mock 這十幾個(gè)依賴的對(duì)象。不管是從代碼設(shè)計(jì)的角度來(lái)說(shuō)，還是從編寫單元測(cè)試的角度來(lái)說(shuō)，這都是不合理的文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-424744.html
總結(jié)一下
單元測(cè)試好像寫的沒(méi)有之前多了，更多的是寫相對(duì)更粗粒度的接口測(cè)試，一個(gè)主要原因就是覺(jué)得寫單元測(cè)試瑣碎，寫接口測(cè)試能通就證明主流程OK，就能提測(cè)了，事實(shí)上在比較緊湊的迭代節(jié)奏里這是常態(tài)，幸而測(cè)試同學(xué)的集成測(cè)試比較給力，沒(méi)出什么問(wèn)題，但其實(shí)也不能老依賴于接口測(cè)試和集成測(cè)試，單元測(cè)試也有必要寫的，更多的是通過(guò)寫單測(cè)CR下自己的代碼吧，踐行持續(xù)重構(gòu)的理念。對(duì)于代碼的可測(cè)試性而言，其實(shí)我們?nèi)粘；赟pring去開(kāi)發(fā)，本身大多數(shù)場(chǎng)景都是依賴注入，所以體會(huì)可能沒(méi)有那么深，至于對(duì)于遠(yuǎn)程服務(wù)的依賴，使用二次封裝是個(gè)不錯(cuò)的方法，但是代碼侵入性還是有一些的，其實(shí)也能通過(guò)一些測(cè)試工具例如AnyMock解決。重要的還是要有單測(cè)和提高代碼可測(cè)試性的意識(shí)吧…文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-424744.html
到了這里，關(guān)于【Java設(shè)計(jì)模式 規(guī)范與重構(gòu)】 二 重構(gòu)的保障：?jiǎn)卧獪y(cè)試，以及如何提高代碼可測(cè)試性的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
