將 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 模式，實際上，上面所闡述的多級認證問題本身比較適合采用這種模式來解決，能夠根據需要繞過部分實現，只是應用這種模式的情況下進行單元測試的一種可以考 慮的測試途徑。
單 元測試是軟件開發的重要組成部分，而應用 Mock Object 是進行單元測試一種普遍而有效的方式，通過在軟件設計、開發的過程中合理地運用設計模式，不但為系統重構、功能擴展及代碼維護提供了方便，同時也為單元測 試的實施提供了極大的靈活性，可以有效降低單元測試編碼的難度，方便地在單元測試中引入 Mock Objects，達到對被測試目標進行單元測試的目的，從而更好地保證軟件開發的質量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
