對於mock object使用工廠模式。但如果有spring支援，可以實現mock物件的非侵入式替換，這個更方便
我們可以考慮採用chain of responsibility 模式將不同的認證邏輯封裝到不同的requesthandler 中，並通過編碼或者根據配置，將所有的handler 串聯成responsibility chain ；而在單元測試過程中，可以修改handler 的串聯方式，繞過部分不希望在單元測試中經過的handler，從而簡化單元測試的執行。
都是通過乙個類（物件例項）來專門負責物件的建立工作（工廠物件），它們之間的區別是：builder模式重在複雜物件的一步步建立（並不直接返回物件），abstractfactory模式重在產生多個相互依賴類的物件，而prototype模式重在從自身複製自己建立新類。
prototype模式的應用場景：
- 在建立物件的時候，我們不只是希望被建立的物件繼承其基類的基本結構，還希望繼承原型物件的資料。
- 希望對目標物件的修改不影響既有的原型物件（深度轉殖的時候可以完全互不影響）。
- 隱藏轉殖操作的細節。很多時候，對物件本身的轉殖需要涉及到類本身的資料細節。
原型引入的根本原因就是在於它可以利用乙個原型物件（在這，我指的是例項，而非類），快速地生成一批和原型物件一樣的例項。舉個例子來說，你有乙個類a的例項a (a a=new a()),現在你想生成乙個和a一樣的例項b,那麼，按照原型的定義，你應該可以這樣做b=a.clone()。這樣，你就可以得到乙個和a一模一樣的例項b(即a和部b的資料成員的值完全一樣）。
上面是原型的乙個簡單說明，那麼引入原型有什麼好處呢？按我的理解，就是在於：你如果要生成一大批很相像的類的例項時，省得每次去做重複的賦值工作。你只要生成乙個a的例項，再通過clone來生成其它的例項，然後再一一修改其它例項不同的地方。
單元測試中的常用測試模式
單元測試跟軟體設計一樣，有一些常用的模式，這篇文章1 準備，執行，斷言 arrange，act，assert 這種模式是非常常見的，套用這種模式進行單元測試通常的做法如下 1 準備測試環境，測試資料等 2 執行被測試方法 3 用斷言來驗證執行結果 下面是一段測試 被測方法的功能是把字串中每個單詞的首...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...