该 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 的原创文章，尽在：” 汪子熙 ”: