Front-end development: automation practice based on cypress

As a pseudo-development, I am responsible for front-end development in a platform project. The development framework is vue. In this article, I will introduce from the perspective of front-end development, how I use cypress.

[x] How to use cypress in vue
[x] How to run cypress
[x] How to write test cases
[x] How to solve the problem of test data
[x] The problem of element positioning encountered
[x] How to treat cypress
[x] Is cypress the best tool?
[x] What about testing?

How to use cypress in vue

Coupon is free to receive m.fenfaw.cn

Vue provides a vue-cliquick way to create a vue project.

vue create hello-world

Select in the select installation item: E2E testing-> cypress.

How to run the test

Start by command

> npm run test:e2e

Open the cyprss management window

Click Run all specsor run a test file

Taking the 项目管理module as an example, it only takes 14s to run 5 use cases, which is very fast.

How to write test cases

From the perspective of front-end development to write UI automation use cases, the overall experience is still very convenient!

First, set uniform attributes for all elements to be manipulated.

<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 is not recommended to take up the offer id, name, class... these attributes, they usually have a designated purpose, for example, classis used to reference css styles. Then cy-data=xxxxit can avoid conflicts and be more unified and standardized.

Next, is to write cypress automation code

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()  // 保存项目
  });
  // ...
})

How to solve the problem of test data

We write automated test cases, regardless of the interface or UI will face the problem of test data. For example, if I want to test login, I have to create a user data first, and if I want to test search, I need to create a batch of searchable data first.

For this reason, we have to use setUp/treaDownthese fixtures in automation to write a large number of pre- or post-actions to complete these preparations. From the perspective of testing, this undoubtedly makes our test cases more complicated, and then it is easy to cause automation use cases to fail due to test data.

So, how does the front-end development work? Before that, we must first understand the development process:

During the project development process. In order to complete the development work more smoothly, the front-end cannot wait until the back-end has developed the interface before handwriting the front-end functions. Therefore, after the interface is defined with the back-end, the interface data is simulated through mock, which is oriented to mock development .

So in the process of mock-oriented development, it is unavoidable that the front and back ends need to adjust the interface parameters. For example, the front end needs to add a field, or the back end says that the data structure needs to be adjusted.

We use the internet YAPI defined interface, he can define the mock data generated randomly, each field data can be randomly generated, e.g., name, email, datatimeand the like.

You can directly access the mock interface through the following link:

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

How to configure different environments in a vue project? You need to learn vue development...

Problems encountered in element positioning

However, adding positioning methods to each element is sometimes not as simple as we think.

If you have used front-end UI (e.g. element-ui) libraries, you will find that not all page elements are purely handwritten in HTML. For example, the following pop-up window.

The implementation through element-UI is like this.

<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>

Pop completely through the element-UI rendering, we have nowhere to 确定, 取消such as buttons plus a dedicated property positioning. At this time, front-end development has no advantages. You must honestly locate elements on the front-end page and write complex css positioning.

However, even if I customize the positioning, sometimes the element is not unique. E.g

For the above list, 自定义定位the result is a set of elements. However, if it’s just a group of elements, there is no need to talk about it separately. As shown in the figure above, there are 4 elements in the list, and 8 elements are obtained by positioning, and the first 4 are hidden. This is related to the element-UI library used, because the data is randomly generated by YAPI, and the fifth display element cannot be manipulated. cypress provided forcevery useful, he would force a hidden element to operate.

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

How to look at cypress

Front-end development perspective

As a front-end developer, objectively speaking, the process of using cypress did not encounter much resistance. Let me summarize.

Because yapi is used, there is no need to consider the preparation of test data.
There is no need to write dependent steps, mainly because the current business functions do not have too long operating procedures.
In most cases, you can customize element attributes, and you don't need to spend too much time on positioning, and you don't need to write too long positioning.
The test running speed is acceptable, and the running of 28 use cases takes about 80 seconds.

Test perspective

As an automated test, if you let me use cypress.

In order to verify the correctness of the data, I cannot ask developers to use yapi fake data, so I still have to prepare the data myself.
According to the business situation, necessary pre/post actions are inevitable.
Although it is a bit difficult to convince the development of a unified custom element, I say it is not impossible!
Cypress does UI automation faster than selenium, but compared to selenium, it does not support more browsers, does not support Grid remote calls, and cannot even choose a language based on your proficiency. Therefore, the advantages of cypress are not overwhelming, and the specifics still depend on the demand.

Is cypress the best tool

Is cypress the best tool for all UI automation?

Vue/ReactCypress is indeed well integrated in the front-end development framework , which makes our use more convenient.

Selenium is well integrated in the partial back-end django web framework I came into contact with, and similar effects can also be achieved. I have read a "Test-Driven Development with Python" before. The book combines Selenium-based UI testing with Django development.

Therefore, the conclusion is to choose the appropriate E2E test tool in combination with your development framework.

What about testing?

For a long time, we have naturally believed that UI automation testing should be done by testing, with the high-level goal of being able to do UI automation testing! But from my practice above, we will find that in fact, the advantages of developing for UI automation are obvious. So what about the test? Can we only go back to test the function honestly? of course not.

Not every developer knows how to write UI automation tests, although it is not particularly difficult for them. We become "coaches" in this regard, teaching developers how to write UI automation tests and how to design more comprehensive test cases.
Not every team's development team has time to write UI automation tests, or they are unwilling to write, so why don't we join them? In the way I introduced earlier, I am deeply involved in the preparation of automated tests for the project. Instead of doing so, the project development and automated testing are completely separated and carried out separately.

During the Spring Festival, I re-read the "Google Test Method", and I have a new feeling. Under the premise of sufficient test development ability, when the team’s goal is to improve the quality of the product, the question of who will do the automated test becomes irrelevant. So important.