應用設計模式編寫易于單元測試的代碼[9] 單元測試方法
與 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 后繼續進行進一步的業務邏輯處理。
在保證多級認證模塊已被專門的單元測試覆蓋的情況下，我們在為業務邏輯編寫單元測試的過程中可以考慮跳過多級認證授權模塊(對于部分特權用戶，也應跳過部分檢查)，直接為其分配一個 Mock 的 sessionId，以進行后續處理。軟件測試
對于多級認證問題本身，我們可以考慮采用 Chain of Responsibility 模式將不同的認證邏輯封裝到不同的 RequestHandler 中，并通過編碼或者根據配置，將所有的 Handler 串聯成 Responsibility Chain ;而在單元測試過程中，可以修改 Handler 的串聯方式，繞過部分不希望在單元測試中經過的 Handler，從而簡化單元測試的運行。
對于這個問題，筆者并不同意為了單元測試的需要去采用 Chain of Responsibility 模式，實際上，上面所闡述的多級認證問題本身比較適合采用這種模式來解決，能夠根據需要繞過部分實現，只是應用這種模式的情況下進行單元測試的一種可以考慮的測試途徑。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
