SAP Spartacus的Lock Focus Directive单元测试实现

测试用的HTML页面：

这些方法可以全部mock：

在beforeEach实现里，选取每一组的部分子元素，注入到service.findFocusable的返回结果集里。

第一组测试：id为a的a标签，tabindex应该被设置为0：

lockFocus directive的默认配置：

注意shouldLock的标志位是通过config.lock决定的：

b标签通过显式传入的lock：true，也将tabindex设置为0，这一点同a标签一样：

c标签：如果显式地传入lock:false：

则host元素的tabindex不发生变化，仍然是初始值5：

在configuration测试里，监控event对象的stopPropagation方法，并且让service的hasFocusableChildren方法返回false.

显式触发a标签的回车事件：

注意上图代码，在使用代码触发a标签的keydown.enter事件时，也要将mock过后的event对象传到event handler里去。

根据lockFocus directive的实现，在handleEnter方法里会调用event.stopPropagation:

如果lock=false，则enter事件触发后，不应该自动被unlock, 单元测试代码：

原因在于，如果lock=false，shouldLock也为false，因此无法进入下图的IF分支。

子元素的锁定测试：

b1，b2, b3应该全部被锁住，tabindex为-1：

为什么要tick(500)?

只要lock=true，就会自动将autofocus设置为true：

在view渲染完毕之后，会调用handleFocus:

handleFocus里会调用setTimeout执行lockFocus方法：

b4，b5属于non-focusable标签，不应该被lock：

b4没有href属性，b5是p标签，都不应被锁住。

如果lock=false，也不应被lock，tabindex不应该为-1：

如果child具有persisted focus，那么不应再lock：

d1和d2的定义：

enter事件触发时，执行unlockFocus方法：

unlockFocus会将子元素的tabindex设置成0：

persist group的测试：

b1,b2,b3会自动被添加上data-cx-focus-group的属性，值为config里传入的g1：

b4, b5不是focusable element，所以不应该被设置data-cx-focus-group属性。

id为a的a标签会在escape时触发service的handleEscape方法：

如果lock=false，那么escape时没必要unlock：