乐趣区

关于sap:SAP-电商云-Spartacus-UI-DeliveryComponent-的依赖设计

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

退出移动版