UI自动化cypress：第一个脚本

之前写了cypress的安装，是未完待续的，一年之后，来继续...

先新建一个空文件脚本sample.js，如图：

而cypress是实时监控变化的，它马上就发现并展示出来了：

虽然我们还没有写任何有意义的内容在sample.js里，但是我们可以点一下，看看这个cypress框架帮我们做了什么：

它调起了chrome浏览器，并且说没有找到tests，这就对了，本来就没有写tests.

写tests时会用到一些方法，来自于cypress集成的一些流行的工具和框架，比如

• describe and it come from Mocha
• expect comes from Chai

我们在脚本文件中第一次写入的内容如下：

describe('My First', () => {
  it('Visits Huawei Cloud', () => {
    cy.visit('https://bbs.huaweicloud.com/')
  })
})

保存后，发现cypress监控到文件更新后，自动就马上执行了：

这里我们访问的是华为云的网站。当然这个网站不在我的控制之下，cypress建议不要这样做，但是我觉得没有什么关系，不能开始就被一些并非原则性的规定所约束而放不开手脚，不得前进。

常用的方法：

.contains('网页上的文本') ，可以加链式调用，.click()

.get('css样式定位选择器')

等等

其他：

1.cypress的功能框架，是挺丰富、方便，也是易用的。可以看到，这些功能都是做在了与访问目标网站相同的浏览器的页面里。

所以cypress对于网页，应该是有侵入性的。

2.对于登录，如果不合预期，在关键点加一些延时，往往就有效果。

最后，这里摘录一段cypress与纯UI（selenium)之间的差异，或者说cypress的更特别、优异之处：

Bypassing your UI

When you're writing tests for a very specific feature, you should use your UI to test it.

But when you're testing another area of the system that relies on a state from a previous feature: do not use your UI to set up this state.

Here's a more robust example:

Imagine you're testing the functionality of a Shopping Cart. To test this, you need the ability to add products to that cart. Well where do the products come from? Should you use your UI to login to the admin area, and then create all of the products including their descriptions, categories, and images? Once that's done should you then visit each product and add each one to the shopping cart?

No. You shouldn't do that.

Using your UI to log in is the exact same scenario as what we described previously. Logging in is a prerequisite of state that comes before all of your other tests.

Because Cypress isn't Selenium, we can actually take a huge shortcut here and skip needing to use our UI by using cy.request().

Because cy.request() automatically gets and sets cookies under the hood, we can actually use it to build up state without using your browser's UI, yet still have it perform exactly as if it came from the browser!

Let's revisit the example from above but assume we're testing some other part of the system.

describe('The Dashboard Page', () => {
  beforeEach(() => {
    // reset and seed the database prior to every test
    cy.exec('npm run db:reset && npm run db:seed')

    // seed a user in the DB that we can control from our tests
    // assuming it generates a random password for us
    cy.request('POST', '/test/seed/user', { username: 'jane.lane' })
      .its('body')
      .as('currentUser')
  })

  it('logs in programmatically without using the UI', function () {
    // destructuring assignment of the this.currentUser object
    const { username, password } = this.currentUser

    // programmatically log us in without needing the UI
    cy.request('POST', '/login', {
      username,
      password,
    })

    // now that we're logged in, we can visit
    // any kind of restricted route!
    cy.visit('/dashboard')

    // our auth cookie should be present
    cy.getCookie('your-session-cookie').should('exist')

    // UI should reflect this user being logged in
    cy.get('h1').should('contain', 'jane.lane')
  })
})

Do you see the difference? We were able to login without needing to actually use our UI. This saves an enormous amount of time visiting the login page, filling out the username, password, and waiting for the server to redirect us before every test.

Because we previously tested the login system end-to-end without using any shortcuts, we already have 100% confidence it's working correctly.

Use the methodology above when working with any area of your system that requires the state to be set up elsewhere. Just remember - don't use your UI!