該 Component 具有5個依賴：

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

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

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

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

• ActiveCartService
• UserIdService
• CheckoutService
  以 ActiveCartService 為例:

使用如下代碼：

class ActiveCartServiceStub implements Partial<ActiveCartService>

可以構(gòu)造一個 MockActiveCartService 出來。

使用 Partial 方法，可以只實現(xiàn) ActiveCartService 的部分方法。

TestBed 用于創(chuàng)建待測試的組件及依賴：

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

看下圖的單元測試代碼：

inject 接受兩個參數(shù)，第一個參數(shù)類型是數(shù)組，存放帶注入的 token，本例是 checkoutDeliveryService，第二個參數(shù)是一個函數(shù)，這個函數(shù)包含業(yè)務(wù)邏輯，且輸入?yún)?shù)為第一個參數(shù) token 數(shù)據(jù)待注入的內(nèi)容。當(dāng)該函數(shù)被調(diào)用時，輸入?yún)?shù)的 token 包含了被 Angular DI 框架注入好的實例。這個用法很像 SAP UI5 異步加載 library 依賴的實現(xiàn)方式。

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

然后調(diào)用 TestBed.inject(Store)

接下來就可以調(diào)用該方法返回的實例的 dispatch 方法，往 store 里插入測試數(shù)據(jù)了。

getSupportedDeliveryModes 方法內(nèi)部會調(diào)用 loadSupportedDeliveryModes，因此使用 spyOn 方法，就可以監(jiān)控后者是否被調(diào)用過。

一旦調(diào)用 service 的 setDeliveryMode 方法，就會觸發(fā) store.dispatch 操作，因此 loading 標(biāo)志位會設(shè)置為 true

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

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。