探索----面向单元测试编写React组件

继上一篇探索----面向单元测试编写React组件之后，笔者开始探索如何能保证我们播放中的落地页进行高质量的产品迭代。

先来体验一下我们的业务，目前我们的平台每天会服务于广告主制作各种各样的落地页，那么我们希望在发布新功能的同时，同时能够快速验证老的特性能够不受影响。

那么为了完成这个目标，我们可以让测试同学回归下本次修改可能涉及到的特性，来确保功能的正常，

• 解决方案一： 如果每一次代码合并master之后就要验证一次，这样的工作可能会让测试同学感到厌烦，因为会有大量重复性的工作
• 解决方案二： 但是如果只验证最后将要发布的master代码时，一旦出现了问题，不能马上定位到具体是哪一次merge所带来的影响，因此不能快速修复该问题。

看来上述两种方案都不是最好的，我们希望能够通过机器自动化的帮我们回归已有功能，因此，我们的自动化测试也因此而诞生。

首先，我们先来思考下我们业务中哪些功能需要回归

1. 样式ui 我们给广告主提供了强大的自定义ui样式功能，能够快速的帮助广告主创建出精美的落地页，那么我们一定希望以往的ui不会受到影响
2. 样式按钮交互，在点击之后，能够符合预期

解决问题一：样式ui问题

我们如何能够让机器知道这个组件的样式是渲染正常的呢？

之前分享jest的snapshot给了启发，那就是快照的概念，如果我们能够保存一份正确渲染的组件图片，那么我们只需要在每次merge进master之后，对比上一次的快照图片，如果图片一致，就说明功能是正常的。

那么基于此，我们引入了puppeteer的截图功能，在我们每一次代码merge进入master之后，触发了我们的ci流程后，就调用puppeteer，对我们已经创建好的一份最全的组件功能页面进行截图，与上一次保存的图片进行比较，看似实现到这里，已经没有了什么问题，那有serverless什么事呢，难道又是标题党蹭热度？

但是我们会发现，我们调用ci执行的docker环境中需要拉取我们自己创建的docker镜像，这个镜像里面需要包含puppeteer和一些基础库，那么拉取镜像这个过程本身比执行我们的测试用例耗时的多，那么有没有方法去缩短这段时间呢？

这个时候，serverless就横空出世了！

serverless可以理解成运行在云上的一个函数，它由事件所触发，然后创建这个函数的实例，最后销毁，我们只需要去编写这个函数本身的代码即可。

当我们持续优化我们的测试流程时，我们播放端的ci构建就简化成了这样的一段代码

curl http://serverless.example.com

我们只需要触发serverless云函数，之后的puppeteer爬取测试用例页面，截图之后，我们将生成的图片保存在腾讯的cos上，然后在邮件发送测试报告即可，整个自动化测试，只需要3s就可以完成，大大缩小了之前的执行时间。

写到这里，我们已经完成了第一步的ui截图快照功能。

但是整个自动化流程中，还有可以持续优化的地方

• 如何能够让机器自己识别两次图片是否一致呢？
• 未完成的点击交互测试