前端开发之cypress的自动化实践

前端开发之cypress的自动化实践本站　　不建议占用HTML提供的的 id、name、class... 这些属性，他们一般都会有指定的用途，比如，class 是用来引用css样式的

　　不建议占用HTML提供的的 id、name、class... 这些属性，他们一般都会有指定的用途，比如，class 是用来引用css样式的。那么通过cy-data=xxxx即可以避免冲突，又更加统一和规范。【关注尚硅谷，轻松学IT】

　　我们编写自动化测试用例，不管是接口还是UI都会面临测试数据的问题。比如，我要测试登录，得先去创建一个用户数据，我要测试搜索，先去创建一批可以搜索的数据。

　　为此，我们不得不在自动化里面 使用setUp/treaDown这些fixture去写大量的前置或后置动作，来完成这些准备工作。站在测试的角度，这无疑让我们的测试用例变得复杂，然后，也很容易因为测试数据造成自动化用例的失败。

　　在项目开发过程中。前端为了更顺利的完成开发工作，不能等到后端开发好了接口，再手写前端功能，所以，会和后端定义好接口之后，通过mock来模拟接口数据，--面向mock开发。

　　那么在面向mock开发的过程中，避免不了，前后端需要调整接口参数的情况，比如，前端需要增加一个字段，或后端说需要把数据结构调整一下。

　　如果你是使用过前端UI（例如 element-ui）库就会发现，并不是所有的页面元素都是通过HTML纯手写的。例如，下面的弹窗。

　　弹窗完全通过 element-UI 渲染，我们无处给 确定、取消 等按钮加上定位专用属性。这个时候，前端开发就没什么优势了，必须老老实实的去前端页面上定位元素，写复杂的css定位。

　　对于上面的列表，通过自定义定位得到的是一组元素。然而，如果只是一组元素的问题就就没必要单独拿出来说了，正如上图，列表中看到的是 4 个元素，通过定位方式得到的是8个元素，前4个是隐藏的，这和使用的 element-UI 库有关，因为数据是YAPI随机生成的，不能写死对第5个显示元素进行操作。cypress 提供的 force 非常有用，他会强制对隐藏的元素进行操作。

　　在面向前端的开发框架Vue/React中 确实很好的整合cypress，使我们的使用更加方便。

　　一直以来，我们都天然的认为UI自动化测试就应该是测试来做的，并以能做UI自动化测试为高级目标！但从我上面的实践中，我们会发现其实开发来做UI自动化优势很明显。那么测试怎么办？我们只能老老实实的回去测功能了吗？当然不是。

　　并不是每个开发都懂得编写UI自动化测试，虽然，这对他们来说并不是特别难，我们完全在这方面成为“教练”，教开发如何编写UI自动化测试，如何设计更全面的测试用例。

　　并不是每个团队的开发都有时间编写UI自动化测试，也可能是他们不愿意写，那么我们为何不加入他们？以我前面介绍的方式，深度地参与到项目的自动化测试编写中。而不是现在这样，将项目开发和自动化测试完全割裂开分别进行。