测试用的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：
