前端业务组件的集成测试

[PainAndLove]

最近写业务组件相关测试代码时，感觉想通过测试把页面上所有组件的每种表现情况都包含进去有点不现实。

假设现在有 A B 两个业务组件。分别请求 apiA 和 apiB 两个接口。那么至少就有 A 组件请求 成功 /失败 与 B 组件请求 成功 /失败 2x2 4 个用例(还没有包括别的情况，比如接口中返回了各种状态，还有各种组件的交互行为，这样就需要写更多)。如果还有别的组件 那么用例的数量至少是 2 的 N 次方。

当然，如果只是与业务逻辑无关的工具函数，那编写测试用例就很容易了，直接输入 /输出一把梭就搞定了，毕竟它们之间没有耦合关系。

所以之前的测试代码遇到上述的情况，也只是分别把 对应组件成功 /失败 单独写一份(有点单元测试的感觉)。并没有包含其他组件。

感觉这样写用例其实并没有达到想象中的效果，因为它只是单元测试，并没有将这些组件放在一起测试。

结论:

考虑使用 jest 的 snapshot 生成组件渲染之后的快照,来“间接”完成业务组件的用例编写。 比如在上述的情况中的 4 个用例，直接用 matchSnapShot 生成快照，通过 diff 来判断改动后的代码生成的快照和之前是否一致。

优点: 相比之前，可以少写大量用例代码。

缺点: 后续维护 snapshot 时，需要仔细判断 snapshot 中某段 diff 是不是符合预期。不能像一般的 expect 那样 直接返回期望值和实际值那样直观。

[thulof]

尽量写成纯函数，每个函数只关心自己。之前没意识到这一点，写测试的时候搞得很复杂。其实理想状态是写测试用例不需要了解内部实现。

[thulof]

晕，竟然是同事。。。

[datou]

看到跳刀就下意识点进来了....

[justyy]

看到跳刀就点进来了， 楼主用的是啥英雄？ ursa? sk?

[seki]

snapshot 和你看某个元素的具体值不冲突，两个可以结合起来做

除了 snapshot 文件，还有 inline snapshot，这个是在测试代码里面更新的，应该更醒目

snapshot 的存在意义还包括如果有回归，可以根据修改历史定位到引入回归的提交，有总比没有好

[orzorzorzorz]

用例这东西，一向都是出了问题修完再补的。没辙，数量问题靠时间堆吧。快照这东西尽量少用，毕竟一个 -u 就解决了，不明白的人很容易这么干。

[PainAndLove]

@orzorzorzorz 也是，一开始不可能把所有的情况全写在用例里。而且也没有必要。