應用設計模式編寫(xiě)易于單元測試的代碼[9] 單元測試方法
與 CacheFactoryImpl 類(lèi)似地，我們實(shí)現了一個(gè) MockCacheFactory，但與 CacheFactoryImpl 不同的是，這個(gè) MockCacheFactory 所創(chuàng )建的 MockCache 對象雖然與真正的 Cache 實(shí)現了相同的接口，但是，它的內部實(shí)現卻是基于 HashMap 的，因此，可以很好地滿(mǎn)足單元測試快速、方便地運行的需要。
單元測試時(shí)，只需要在 setUp 時(shí)調用執行如下操作：
setDelegate(new MockCacheFactory());
將 CacheFactory 的實(shí)現委托給 MockCacheFactory 即可，所有業(yè)務(wù)邏輯都無(wú)需作任何修改，因此，這種替換實(shí)現的方式幾乎是沒(méi)有侵入性的。
這種通過(guò)將實(shí)現分離到專(zhuān)門(mén)的實(shí)現類(lèi)中的做法其實(shí)是 Bridge 模式的一個(gè)應用，通過(guò)使用 Bridge 模式，為替換實(shí)現保留了接口，從而使得在不對業(yè)務(wù)邏輯作任何修改的情況下可以輕松替換公共服務(wù)的實(shí)現。
除此之外，Strategy 模式也是一種替換實(shí)現的有效途徑，這種方式與 Factory Method 類(lèi)似，通過(guò)子類(lèi)化實(shí)現新的 Strategy 以替換業(yè)務(wù)邏輯使用的舊的 Strategy，通過(guò)與 Factory Method 或 Bridge 等模式聯(lián)合使用，在編寫(xiě)應用公共服務(wù)的業(yè)務(wù)邏輯的單元測試時(shí)也十分有用。
繞過(guò)部分實(shí)現
繞過(guò)部分實(shí)現進(jìn)行單元測試在大多數情況下是不可取的，因為這種做法極有可能會(huì )影響單元測試的質(zhì)量。但是對于一些特殊的情況，我們可以“冒險”使用這種方式，比如有這樣的一個(gè)場(chǎng)景：所有請求需經(jīng)過(guò)多級認證，且部分認證處理需要訪(fǎng)問(wèn)數據庫，認證結束后為請求分配相應的 sessionId，請求在獲得 sessionId 后繼續進(jìn)行進(jìn)一步的業(yè)務(wù)邏輯處理。
在保證多級認證模塊已被專(zhuān)門(mén)的單元測試覆蓋的情況下，我們在為業(yè)務(wù)邏輯編寫(xiě)單元測試的過(guò)程中可以考慮跳過(guò)多級認證授權模塊(對于部分特權用戶(hù)，也應跳過(guò)部分檢查)，直接為其分配一個(gè) Mock 的 sessionId，以進(jìn)行后續處理。軟件測試
對于多級認證問(wèn)題本身，我們可以考慮采用 Chain of Responsibility 模式將不同的認證邏輯封裝到不同的 RequestHandler 中，并通過(guò)編碼或者根據配置，將所有的 Handler 串聯(lián)成 Responsibility Chain ;而在單元測試過(guò)程中，可以修改 Handler 的串聯(lián)方式，繞過(guò)部分不希望在單元測試中經(jīng)過(guò)的 Handler，從而簡(jiǎn)化單元測試的運行。
對于這個(gè)問(wèn)題，筆者并不同意為了單元測試的需要去采用 Chain of Responsibility 模式，實(shí)際上，上面所闡述的多級認證問(wèn)題本身比較適合采用這種模式來(lái)解決，能夠根據需要繞過(guò)部分實(shí)現，只是應用這種模式的情況下進(jìn)行單元測試的一種可以考慮的測試途徑。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
