該 Component 具有5個依賴：

為了修復 bug，我需要引入 checkout service 和 cart service.

如果直接在該構造函數里注入，這實際上算是修改了 constructor signature，按照 Spartacus 編程規范，這算是引入了 breaking change - 重大更改。

但我們觀察到，該 Component 類的依賴之一，checkoutDeliveryService 內部，具有 checkout service 和 cart service.

如此一來，我們可以把代碼移到 checkoutDeliveryService 里編寫，這樣就不會在 Delivery Component 里引入依賴了。
我們分析上圖 Checkout Delivery Service 類，其具有5個依賴，兩個 store，存儲 state 信息，三個 service 類：

• ActiveCartService
• UserIdService
• CheckoutService
  以 ActiveCartService 為例:

使用如下代碼：

class ActiveCartServiceStub implements Partial<ActiveCartService>

可以構造一個 MockActiveCartService 出來。

使用 Partial 方法，可以只實現 ActiveCartService 的部分方法。

TestBed 用于創建待測試的組件及依賴：

上圖的 TestBed.configureTestingModule 只是第一步，還需要調用 TestBed.inject 方法，注入上圖 82，83 和 84 行 provide 后面的方法名，返回被注入的類實例：

看下圖的單元測試代碼：

inject 接受兩個參數，第一個參數類型是數組，存放帶注入的 token，本例是 checkoutDeliveryService，第二個參數是一個函數，這個函數包含業務邏輯，且輸入參數為第一個參數 token 數據待注入的內容。當該函數被調用時，輸入參數的 token 包含了被 Angular DI 框架注入好的實例。這個用法很像 SAP UI5 異步加載 library 依賴的實現方式。

而 Ngrx store 的依賴 mock，我們需要在 TestBed.configureTestingModule 的 imports 區域里，維護真實的 StoreModule.forRoot 和 forFeature 返回的數據。

然后調用 TestBed.inject(Store)

接下來就可以調用該方法返回的實例的 dispatch 方法，往 store 里插入測試數據了。

getSupportedDeliveryModes 方法內部會調用 loadSupportedDeliveryModes，因此使用 spyOn 方法，就可以監控后者是否被調用過。

一旦調用 service 的 setDeliveryMode 方法，就會觸發 store.dispatch 操作，因此 loading 標志位會設置為 true

又比如 reset 方法，底層會調用 store.dispatch 操作，且傳入一個 ResetSetDeliveryModeProcess 的 action. 這個調用也可以被監控。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的SAP 电商云 Spartacus UI DeliveryComponent 的依赖设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。