應用設計模式編寫易于單元測試的代碼

發布: 2009-12-24 14:09 | 作者: 不詳 | 來源: 領測國際測試網采編 | 查看: 23次 | 進入軟件測試論壇討論

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); } } }

　　與 CacheFactoryImpl 類似地，我們實現了一個 MockCacheFactory，但與 CacheFactoryImpl 不同的是，這個 MockCacheFactory 所創建的 MockCache 對象雖然與真正的 Cache 實現了相同的接口，但是，它的內部實現卻是基于 HashMap 的，因此，可以很好地滿足單元測試快速、方便地運行的需要。

　　單元測試時，只需要在 setUp 時調用執行如下操作：

setDelegate(new MockCacheFactory());

　　將 CacheFactory 的實現委托給 MockCacheFactory 即可，所有業務邏輯都無需作任何修改，因此，這種替換實現的方式幾乎是沒有侵入性的。

　　這種通過將實現分離到專門的實現類中的做法其實是 Bridge 模式的一個應用，通過使用 Bridge 模式，為替換實現保留了接口，從而使得在不對業務邏輯作任何修改的情況下可以輕松替換公共服務的實現。

　　除此之外，Strategy 模式也是一種替換實現的有效途徑，這種方式與 Factory Method 類似，通過子類化實現新的 Strategy 以替換業務邏輯使用的舊的 Strategy，通過與 Factory Method 或 Bridge 等模式聯合使用，在編寫應用公共服務的業務邏輯的單元測試時也十分有用。

　　繞過部分實現

　　繞過部分實現進行單元測試在大多數情況下是不可取的，因為這種做法極有可能會影響單元測試的質量。但是對于一些特殊的情況，我們可以“冒險”使用這種方式，比如有這樣的一個場景：所有請求需經過多級認證，且部分認證處理需要訪問數據庫，認證結束后為請求分配相應的 sessionId，請求在獲得 sessionId 后繼續進行進一步的業務邏輯處理。