E2E 测试之 Cypress

E2E 测试之 Cypress

背景

写测试好像一直是横亘在开发眼前的一个问题,在业务开发时间比较紧急的时候,测试可能是第一个被抛弃的(境界不够。

在实际业务开发中有几次修改代码后因为测试不充分,发布后原功能受影响。所以我们当前的首要需求是快速回归产品功能,尽量保证原有业务不能受到影响同时可以节省测试资源,在选择测试方式的时候就偏向于 E2E 测试。

现在有一些测试框架可供选择,CasperJS、Nightwatch 等等。CasperJS 只能是无界面浏览器测试,不列入考虑。在 TestCafe 和 Cypress 中犹豫过,TestCafe 支持常见浏览器,支持 ES6/ES7 和 TS,安装也方便。

最终选择了 Cypress,主要是觉得开箱即用,文档比较清晰美观,语法用起来比较舒服,最重要的一点是测试跑在 Chrome 的标签页里,和平时开发没什么区别。这种情况下其实很适合开发时模拟各种场景,比如新增一个接口,约定好了接口定义但是接口还没好,就可以利用 Cypress 来模拟请求开发了。一定程度上也可以实现 mock 的功能。同样,测试 fail 了也可以直接调试。

安装

下载速度比较慢,耐心等待一下。安装完之后根目录下会出现 cypress 文件夹,文件夹目录结构如下:

|-- fixtures
|-- integration
|   `-- example_spec.js
|-- plugins
|   `-- index.js
`-- support
    |-- commands.js
    `-- index.js

fixtures 文件夹存放自定义 json 文件,integration 文件夹编写测试,plugins 和 support 是非必须使用的文件夹,需要自定义指令的时候会用到。

编写一个最基础的测试

以一个包含 E2E 测试常用操作的测试用例来介绍 Cypress 的基本使用。结合官方文档给的案例一起看风味更佳。

  1. 打开、跳转网页:打开 eleme h5 订餐首页
  2. 滚动首页餐厅列表,是否正确滚动加载
  3. 填写搜索词,提交搜索,正确跳转页面
  4. 点击搜索第一项,页面正确展示

添加测试文件

在 cypress/integration 文件夹下新建测试文件。如 example.spec.js

根据喜好选择某种风格编写测试

Cypress 对 chai、Expect.js 风格的都支持,还拓展了一些断言,

页面的展示离不开接口的返回结果。根据测试用例模拟不同的接口返回。不建议使用真实请求测试,完全可以自己设计接口返回进行测试。

第一步开启请求拦截:

Start a cy.server()

第二步设置目标请求的相关内容。cy.route() 指定的请求会被拦截下来,可以根据需求修改 response、status 等等:

Provide a cy.route()

另外,设置请求时可以使用 cy.fixture(),通过这个 command 可以指定请求 response 从特定文件读取。

例如:

cy.fixture('list.json').as('listInfo')
cy.route('list', '@listInfo').as('getList')

就是拦截 /list 请求,将返回替换成 cypress/fixtures/list.json 文件的内容。

回到本例,我们首先需要用 cy.visit() 跳转到需要测试的页面。

关于滚动 Cypress 提供了接口 cy.scrollto(),获取 DOM 元素用 cy.get()。用法类似平时使用的 querySeclector。

it('列表滚动加载', () => {
  cy.visit('https://h5.ele.me/')
  // 滚动加载
  cy.scrollTo(0, 600)
  cy.get('.shoplist > section').should('have.length', 10)
})

接下来获取输入框并输入搜多次,输入可以使用 cy.type()

it('输入搜索词,结果正确展示', () => {
  cy.visit('https://h5.ele.me/')
  // 点击跳转搜索页面
  cy.get('.search').click()

  cy.wait(200)
  cy.get('input').type('麻辣烫')

  cy.get('button').click()

  // 目标页面地址包含 search 点击列表第一项
  cy.wait(500)
  cy.url().should('include', 'search')
  cy.get('.shop').first().click()

  // 跳转至商家详情页,找到购物车元素
  cy.wait(500)
  cy.get('.cartview')
})

这里面使用的 cy.wait() 意思是等待多少毫秒,因为接口是真实数据,事实上真实测试的时候使用我们拦截过的请求,一般不需要使用等待某个时间。

一个修改请求的例子

比如我们想模拟 5xx 这种异常返回,当然可以使用 charles 来拦截请求修改状态。但是使用 Cypress 的话,编写测试用例的同时就可以在浏览器模拟场景,检测是否符合预期结果。

cy.route({
  url: /xxxx,
  response: '',
  status: 500
})

测试结果分析

可视化测试结果如下图:

每一个 case 运行的过程和结果会显示在面板上,运行出错不会妨碍其他 case,对于检查结果还是比较清晰明了的。对于运行失败的 case,可以像平时开发一样用 Chrome Devtools 检查 dom 或网络请求。

常用 api

除了上文介绍到的一些接口,还有一些比较常用的api:

Hooks

describe('Hooks', function() {
  before(function() {
    // runs once before all tests in the block
  })
  after(function() {
    // runs once after all tests in the block
  })
  beforeEach(function() {
    // runs before each test in the block
  })
  afterEach(function() {
    // runs after each test in the block
  })
})

cy.viewport()

可以方便的修改视窗,就像使用 Chrome 模拟不同设备窗口一样。比如设置了 cy.viewport('iphone-6') 就会以 iphone6 的大小跑测试。

Environment Variables

类似于全局变量,在根目录下的 cypress.json 中

{
  "env": {
    "foo": "bar",
    "some": "value"
  }
}

便可以在测试文件中通过 Cypress.env('foo') 来访问。

注意:

  • 后端修改接口时,可能需要修改测试中的接口返回,否则可能会不匹配实际情况。
  • Cypress 对多浏览器测试支持并不友好,不能做到像 browserstack 那样测试各个浏览器兼容性。这方面可以看一下 这篇文章。接下来我们也可能使用阿里云移动测试来测试兼容性。
  • Cypress 对 fetch 的兼容不好,处理方法详见 issue95

总结一下使用 Cypress 写测试的基本思路

  • 确定是否需要拦截请求,用 cy.route 修改请求,按照设计好的测试用例设定 response。
  • 用 cy.visit 访问需要测试的页面。
  • 根据实际情况,一般校验元素可见性、是否是禁用状态、数量、文案是否正确等等。
  • 运行测试,在控制面板查看测试结果。

其实上手很快,关键是要了解业务流程,合理划分功能点写测试用例。


关于 Cypress

介绍了基本的使用方法,接下来稍微探究一下这个 Cypress 测试工具。

Cypress 可以概括为是许多测试框架的集合,可以使用 Mocha、Karma、Capybara 等等。用官方的说法是 Cypress 基本上可以取代 Karma 了?。

Cypress esentially replaces Karma because it does all of this already and much more.

Karma 其实是一个 runner,分 client 和 sever。Cyrpess 和 Karma 相似:监听文件,server 与 client 进行通讯,向开发者输出测试结果。

Cypress 并没有使用 Selenium / Webdriver。Cypress 运行在浏览器上下文中,几乎不与外界产生真实交流。当然也提供一些接口比如 cy.request() 可以去真实请求接口。

不过 Cypress 实际上更像是一个程序、一个开发工具,可以测试任何在浏览器里运行的程序,和你所使用的框架是什么没关系。换句话说,可以边测试边开发。

支持的功能和一些关键的特性在 官网 有明确的说明。

一时的使用并不意味着上了终身保险,能满足你的需求才是最重要的。介绍 Cypress 是提供一种比较有意思的测试方式,实际上写的测试效果如何还是取决于你的代码。

编辑于 2018-01-08

文章被以下专栏收录

    只看代码的话,上 https://github.com/ElemeFe 。这一群人,关心的不是「如何写前端」而是「如何很好地运行一个 ( web ) APP」;这一群人,会在监控屏上加上弹幕,会让实习生自主招聘,会设计、编写、监控整个 APP 的生命周期;这一群人,玩的时候... 更卖力,就像从来没来过那般卖力,卖力地热爱生活。所以这些创作大多基于 ❤️