“我正在参加「掘金·启航计划」”
背景
最近写了较多组件测试用例，由于以前没写过组件测试(or 集成测试)，在写的过程中曾有些困惑。
本文主要记录以下问题:
1、组件测试方法(方法论);
2、前端测试代码技巧;
组件测试
一开始我只是考虑测试组件传入不同的props展示是否正常展示，expose的所有方法是否正常调用。
但后来慢慢发现有一些方法/用户操作的场景无法覆盖到(方法之间相互影响)，然后根据测试反馈的bug增加了一些测试用例，但这样写会很奇怪:
为什么只写这些组合的测试用例？举一个简单的例子:
function add(a: number, b: number) {
return a+b
}
function sub(a: number, b: number) {
return a - b
}
// 单独测两种方法
add(a, b)
sub(a, b)
// 组合
add(sub(a, b), c)
add(a, sub(b, c))
sub(add(a, b), c)
sub(a, add(b, c))
这个例子可能不是非常恰当，但可以看出来如果我们要覆盖所有的场景是非常困难的。这导致在写测试代码时非常难受，到底写哪些？不写哪些？还是全部写？怎么评估组件测试是否充分？
目前关于组件测试的文章很少，基本找不到有详细的说明，但我们可以在集成测试中找到指引。
集成测试方法
集成测试分两大类:
一、非增量测试;
大爆炸方法属于非增量式集成测试方法，该方法一次性集成了所有模块，即它不会逐个集成模块。它会在集成后验证系统是否按预期工作。
二、增量测试;
// 1、自顶向下 集成
逐步集成和逐步测试是按结构图自上而下进行的，即：模块集成顺序是首先集成主控模块，然后按照软件控制层次接口向下进行集成。从属于主控模块的模块按照深度优先策略或广度优先策略集成到结构中去。
// 2、自底向上 集成
从最底层的模块开始，按结构图自下而上逐步进行集成并逐步进行测试工作。
// 3、三明治方法
改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。
这里每个分类的优缺点/适用场景/策略等都可以参考集成测试，这里不再展开了。
结论
在了解了集成测试方法后，其实我没有什么可选择空间(没有这么多测试资源来进行增量测试)。
但大量缓解了我的测试焦虑，我只需要进行非增量测试，测试的策略如下：
先独立的测试每个模块（单元测试），然后再把它们组合成一个整体进行测试。
最后结合边界条件尽量cover所有的分支/语句(关于cypress覆盖率可以查看我前一篇文章)。
前端测试技巧
其实在写前端测试代码的时候，经常会遇到一个非常困惑的事情，当我调用了某个方法渲染数据的时候，怎么判断渲染是否正常?我在使用的时候有两个技巧:
1、尽量使用稳定的节点去进行判断，例如我在渲染列表的时候是通过 uniqueId 去检查是否已更新/删除/添加;
2、使用 screenshot diff 功能，但 cypress 仅提供了 screenshot 功能，没提供 diff 的功能，需要通过 cypress 插件来集成进去, e.g. cypress-image-diff-js
这里还是再说明一下 screenshot diff 功能。每次执行生成的 screenshot 如果有不一样就会提示错误，非常适合前端测试，毕竟你不可能每个节点都去检查。但有一些主要注意：
1、不能使用随机mock数据进行渲染;
2、异步渲染数据需要注意(例如图片，需要设置延迟时间或本地加载等);
3、该插件在chrome下分辨率有些问题待处理(https://github.com/uktrade/cypress-image-diff/issues/115, https://github.com/uktrade/cypress-image-diff/issues/122)
3、使用自定义属性选择器(固定作为测试的选择器， e.g. data-testid);
很多时候开发和测试并不是同一个人或者同一组人，使用特定的标识方便进行测试，也方便开发快速辨识到这是测试用的。
参考文档
1、集成测试: blog.51cto.com/u_14082075/…
2、测试技巧: zh-hans.reactjs.org/docs/testin…
