前端開發：基於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測試之道》，有了新的感覺，在測試開發能力足夠的前提下，當團隊的目標是提升產品的保證質量時，自動化測試到底由誰來作的問題變得不那麼重要了。