第1篇: 講述了如何創造"縫". "縫"(seam)是需要知道的概念.
第2篇, 避免在構建對象時寫出不易測試的代碼.
第3篇, 依賴項和迪米特法則.
本文是第4篇, 將介紹全局狀態引起的問題.
全局狀態
全局狀態, 也可以叫做應用程序狀態, 它是一組變量, 這些變量維護着應用程序的高級狀態.
在程序里, 全局狀態可能都存放在一個全局狀態對象里, 例如ASP.NET里面的HttpContext; 或者它們可能是全局的變量, 這些全局變量在程序的任何地方都可以訪問.
不管是如何實現的全局狀態, 每個全局狀態變量在內存里只有一個實例. 所以如果一個類里更新了全局變量的值, 那么另一個類訪問該變量的時候它的值就是剛才被更新的值.
有些情況下, 使用全局狀態確實有用; 但是如果使用不當, 則會對測試造成很大的影響.
全局狀態對測試引起的問題
- 使用靜態方法或全局變量訪問全局狀態的時候, 就引起了對全局狀態的直接耦合. 這很不好.
- 這種耦合就導致很難對測試進行設置. 針對每個測試, 我們必須創建和設置好存儲全局狀態的對象. 或者把全局變量設定為所需的值.
- 因為每個全局狀態變量在內存里只有一個實例, 那么我們就無法進行並行單元測試了. 如果我們為A測試設定了全局變量的值, 然后在測試A結束前開始測試B, 這時測試B修改了全局變量的值, 這時測試A就可能會失敗, 因為它所期待的全局變量不是這個值.
- 上面的這種現象就叫做鬼魅般的超距作用(Spooky Action at a Distance). 而實際項目中確實經常發生這樣的情況, 並行跑單元測試的時候偶爾會失敗, 而單獨去跑失敗的測試時卻一直成功. 這種耦合到全局狀態的測試就不能再稱為隔離測試了.
危險信號
- 全局變量
- 調用靜態字段或調用擁有靜態字段的類的靜態方法. 但也僅限於該類的靜態方法使用了該類的靜態字段.
- 單例模式 (Singleton Pattern)
- 單元測試會隨機的失敗, 但是又沒發現明確的原因.
解決辦法
- 盡量使用本地(局部, 越窄越好)狀態變量
- 如果第三方庫使用了靜態方法, 那么應該使用一個包裝類來對該方法進行包裝. 這個包裝類還是要實現一個接口. 用它的時候注入該接口即可. 這樣測試的時候就可以為包裝類創建測試替身了, 並把全局狀態解耦.
- 使用可依賴注入(IoC/DI)的單例體, 這種單例體是由IoC容器創建的.
例子
就舉一個例子吧.
有這樣一個獲取當前登錄用戶權限的類, 它使用的是單例模式:
這個是典型的單例模式, 它會保證在程序中只返回一個實例, 這里就不多介紹了.
下面這個Service會調用上面這個Auth類:
Auth是單例模式的, 而且還調用了靜態方法.
現在的狀態是, OfficeService和Auth所包含的全局狀態緊密的耦合到了一起.
如何解決問題
首先應該把單例模式去掉, Auth類只保留兩個屬性和一個方法:
然后在service里面應該注入IAuth接口並使用:
那么接下來就需要保證這個IAuth無論在程序中注入了多少次, 都是同一個實例.
這時就需要使用依賴注入(DI) 庫了. 現在的DI庫通常允許指定IoC容器中每對綁定服務的作用范圍(Scope), 或叫做生命周期管理.
例如ASP.NET Core內置的IoC容器就內置了這種功能. 在ASP.NET Core 項目的Startup類里, 這樣寫就可以保證每次請求IAuth的時候只會得到同一個對象實例:
現在這個"單例"的工作是由IoC容器來負責了. 在其它地方正常的注入IAuth使用即可.
先寫到這, 本文的概念性內容和更多的例子請參考Angular創始的人這篇文章: http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/