應用設計模式編寫(xiě)易于單元測試的代碼[8] 單元測試方法
替換實(shí)現
通過(guò) Factory Method 替換被創(chuàng )建對象可以滿(mǎn)足一些修改程序運行路徑的需求，但是，這種方法以子類(lèi)化為前提，具有很強的侵入性，并且在編寫(xiě)單元測試時(shí)，開(kāi)發(fā)人員需要同時(shí)負責 Mock Objects 的開(kāi)發(fā)，供 Factory Method 調用，因此，編碼量往往會(huì )比較大，單元測試開(kāi)發(fā)人員也需對所使用的公共模塊的內部結構有十分清楚的認識。即使可以使用公共的 Mock Objects 實(shí)現避免代碼重復，往往也需要修改業(yè)務(wù)邏輯中公共服務(wù)相關(guān)對象的創(chuàng )建代碼，這一點(diǎn)對于應用公共模塊的業(yè)務(wù)邏輯的單元測試可能不太適合。
在筆者曾參與設計、開(kāi)發(fā)的某應用系統中，有一個(gè)專(zhuān)門(mén)的數據庫緩沖(Cache)公共服務(wù)，該 Cache 負責完成與數據庫交互，實(shí)現數據的存取，并緩存數據以提高后續訪(fǎng)問(wèn)的效率。對于涉及數據庫緩沖的業(yè)務(wù)邏輯的單元測試，需要一個(gè)替代方案來(lái)替代已有的數據庫緩沖，以避免直接訪(fǎng)問(wèn)實(shí)際數據庫，但又要保證這個(gè)替換不會(huì )影響到被測試單元的實(shí)現。
為了解決這個(gè)問(wèn)題，我們并沒(méi)有直接替換 Cache 創(chuàng )建處的代碼，因為這些代碼遍布在業(yè)務(wù)代碼中，直接替換 Cache 創(chuàng )建代碼無(wú)疑會(huì )侵入業(yè)務(wù)邏輯，并需要大量使用子類(lèi)化。為了盡可能降低對業(yè)務(wù)邏輯的影響，我們維持了原有 CacheFactory 的接口，但是將 CacheFactory 的實(shí)現委托(Delegate)給另一個(gè)實(shí)現類(lèi)完成，以下是 CacheFactory 實(shí)現的偽代碼： 軟件測試
package com.cachefactory.demo;
public abstract class CacheFactory {
private static CacheFactoryinstance = new DelegateCacheFactory();
private static CacheFactorydelegate;
protected CacheFactory() {
}
// CacheFactory is a singletonpublic
static CacheFactory getInstance() {
return instance;
}
// the implementation can be changedprotected
static void setDelegate(CacheFactory instance) {
delegate= instance;
}
public abstract Cache getCache(Object... args);
// redirect all request to delegateeprivate
static class DelegateCacheFactoryextendsCacheFactory {
private DelegateCacheFactory() {
}
public Cache getCache(Object... args) {
return delegate.getCache(args);
}
}
}
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
