前端业务组件的集成测试

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

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

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

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

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

结论:

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

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

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