前端开发：基于cypress的自动化实践

做为一个伪开发，在一个平台项目中负责前端的开发工做，开发框架为vue，本文我会站在前端开发的角度介绍，我是如何使用cypress的。

• [x] 如何在vue中使用cypress
• [x] 如何运行cypress
• [x] 如何编写测试用例
• [x] 如何解决测试数据的问题
• [x] 遇到的元素定位的问题
• [x] 如何看待cypress
• [x] cypress是否为最佳工具
• [x] 测试怎么办？

如何在vue中使用cypress

vue提供了vue-cli 能够快速的建立vue项目。

vue create hello-world

在选择安装项里面选择: E2E testing -> cypress。

如何运行测试

1. 经过命令启动

> npm run test:e2e

1. 开启cyprss 管理窗口

2. 点击Run all specs 或 某个测试文件运行

这里以项目管理 模块为例，运行5条用例只须要14s，速度仍是很是快的。

如何编写测试用例

站在前端开发的角度上编写UI自动化用例，整体感觉仍是很是方便的！

首先，为全部要操做的元素设置统一的属性。

<el-button cy-data="create-project" type="primary" @click="showCreate">建立</el-button>
...
<el-button cy-data="edit-project" type="text" size="small" @click="showEdit(scope.row)">编辑</el-button>
<el-button cy-data="delete-project" type="text" size="small" @click="deleteProject(scope.row)">删除</el-button>
...

不建议占用HTML提供的的 id、name、class... 这些属性，他们通常都会有指定的用途，好比，class 是用来引用css样式的。 那么经过cy-data=xxxx便可以免冲突，又更加统一和规范。

接下来，就是编写 cypress 自动化代码了

describe('项目管理', () => {
  it('添加项目', () => {
    cy.visit('/#/project')
    cy.get('[cy-data=create-project]', { timeout: 3000 }).click()
    cy.wait(1000)
    cy.get('[cy-data=project-name]', { timeout: 3000 }).type('项目名称')
    cy.get('[cy-data=project-desc]', { timeout: 3000 }).type('项目备注信息')
    cy.get('[cy-data=save-button]', { timeout: 3000 }).click()  // 保存项目
  });
  // ...
})

如何解决测试数据的问题

咱们编写自动化测试用例，不论是接口仍是UI都会面临测试数据的问题。好比，我要测试登陆，得先去建立一个用户数据，我要测试搜索，先去建立一批能够搜索的数据。

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

那么，站在前端开发是如何解决的？在此以前咱们要先了解一下开发过程：

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

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

咱们使用YAPI平台进行接口的定义，他能够根据定义随机的生成mock数据，数据的每一个字段均可以随机生成，例如，name，email, datatime 等。

你能够直接经过下面的连接来访问mock接口：

https://yapi.baidu.com/mock/40650/api/v1/projects/list

如何vue项目当中配置不一样的环境？你须要去学习vue开发...

遇到的元素定位问题

然而，为每一个元素添加定位方式，有时并非咱们想象的那么简单。

若是你是使用过前端UI（例如 element-ui）库就会发现，并非全部的页面元素都是经过HTML纯手写的。 例如，下面的弹窗。

经过 element-UI的实现方式是这样子的。

<template>
  <el-button type="text" @click="open">点击打开 Message Box</el-button>
</template>

<script>
  export default {
    methods: {
      open() {
        this.$confirm('此操做将永久删除该文件, 是否继续?', '提示', {
          confirmButtonText: '肯定',
          cancelButtonText: '取消',
          type: 'warning'
        }).then(() => {
          this.$message({ type: 'success',  message: '删除成功!' });
        }).catch(() => {
          this.$message({ type: 'info', message: '已取消删除' });          
        });
      }
    }
  }
</script>

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

然而，就算我自定义了定位，有时候元素也不是惟一的。例如

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

cy.get('[cy-data=edit-project]', { timeout: 3000 }).first().click({ force: true })

如何看待cypress

前端开发视角

做为一名前端开发，客观的说，使用cypress的过程并无遇到太多阻力。我来总结一下。

1. 由于使用了yapi，不须要考虑测试数据的准备。
2. 不须要写依赖步骤，主要是目前的业务功能也没有太长的操做过程。
3. 大部分状况下能够自定义元素属性，在定位上不须要花费过多的时间，也不须要写太长的定位。
4. 测试运行速度能够接受，28条用例运行耗时80秒左右。

测试视角

做为一名自动化测试，若是让我使用cypress。

1. 为了验证数据的正确性，我不能要求开发使用 yapi 假数据，因此，仍是要本身准备数据。
2. 根据业务的状况，必需要的前置/后置动做不可避免。
3. 虽然，说服开发统一自定义元素有点难，对来我说并非不可办到！
4. cypress 作UI自动化确实比selenium要快一些，可是他相比selenium，不支持更多的浏览器，不支持Grid远程调用，甚至不能根据本身的熟练度选择语言。因此，cypress 优点并无压倒性优点，具体仍是要看需求。

cypress是否为最佳工具

cypress是否为全部UI自动化的最佳工具？

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

在我接触到的偏后端的django Web框架中就很好的整合了Selenium，一样能够达到相似的效果。 我以前看过一本《Test-Driven Development with Python》 ，书中就很好的将基于Selenium的UI测试与Django开发很好的结合起来了。

因此，结论是结合你的开发框架去选择合适的 E2E 测试工具。

测试怎么办？

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

1. 并非每一个开发都懂得编写UI自动化测试，虽然，这对他们来并非特别难，咱们彻底在这方面成为“教练”，教开发如何编写UI自动化测试，如何设计更全面的测试用例。

2. 并非每一个团队的开发都有时间编写UI自动化测试，也多是他们不肯意写，那么咱们为什么不加入他们？以我前面介绍的方式，深度地参与到项目的自动化测试编写中。而不是如今这样，将项目开发和自动化测试彻底割裂开分别进行。

春节期间重读了《google测试之道》，有了新的感觉，在测试开发能力足够的前提下，当团队的目标是提升产品的保证质量时，自动化测试到底由谁来作的问题变得不那么重要了。