zoukankan      html  css  js  c++  java
  • [Cypress] install, configure, and script Cypress for JavaScript web applications -- part4

    Load Data from Test Fixtures in Cypress

    When creating integration tests with Cypress, we’ll often want to stub network requests that respond with large datasets. All of this mock data can lead to test code that is hard to read. In this lesson, we’ll see how to use fixtures to keep sample data in files and easily load it on demand in your tests.

    If we load test data from the 'it', it is not a clean way, we should do it in fixtures:

    // NOT
    describe('App initialization', () => {
      it('Displays todos from API on load', () => {
        cy.server()
        cy.route('GET', '/api/todos', [
          {id: 1, name: 'One', iscomplete: false},
          {id: 2, name: 'Two', iscomplete: false},
          {id: 3, name: 'Three', iscomplete: false},
          {id: 4, name: 'Four', iscomplete: false},
        ])
        cy.visit('/')
        cy.get('.todo-list li').should('have.length', 4)
      })
    })

    In fixtures folder, to createa new json file called: todos.json:

    [
      {"id": 1, "name": "One", "iscomplete": false},
      {"id": 2, "name": "Two", "iscomplete": false},
      {"id": 3, "name": "Three", "iscomplete": false},
      {"id": 4, "name": "Four", "iscomplete": false},
    ]

    Use it:

    describe('App initialization', () => {
      it('Displays todos from API on load', () => {
        cy.server()
        cy.route('GET', '/api/todos', 'fixture:todos')
    
        cy.visit('/')
        cy.get('.todo-list li').should('have.length', 4)
      })
    })

    Wait for XHR Responses in a Cypress Test

    When testing interactions that require asynchronous calls, we’ll need to wait on responses to make sure we’re asserting about the application state at the right time. With Cypress, we don’t have to use arbitrary time periods to wait. In this lesson, we’ll see how to use an alias for a network request and wait for it to complete without having to wait longer than required or guess at the duration.

    describe('App initialization', () => {
      it('Displays todos from API on load', () => {
        cy.server()
        cy.route('GET', '/api/todos', 'fixture:todos').as('load')
    
        cy.visit('/')
    
        cy.wait('@load')
    
        cy.get('.todo-list li').should('have.length', 4)
      })
    })

    Interact with Hidden Elements in a Cypress Test

    We often only show UI elements as a result of some user interaction. Cypress detects visibility and by default won’t allow your test to interact with an element that isn’t visible. In this lesson, we’ll work with a button that is shown on hover and see how you can either bypass the visibility restriction or use Cypress to update the state of your application, making items visible prior to interacting with them

    cy.get('.todo-list li')
      .first()
      .find('.destroy')
      .invoke('show')
      .click()
    })

    Create Aliases for DOM Elements in Cypress Tests

    We’ll often need to access the same DOM elements multiple times in one test. Your first instinct might be to use cy.get and assign the result to a variable for reuse. This might appear to work fine at first, but can lead to trouble. Everything in Cypress is done asynchronously and you’re interacting with an application’s DOM, which is changing as your tests interact with it. In this lesson, we’ll see how we can reference DOM elements in multiple places with the alias feature in Cypress.

    describe('List Item Behavior', () => {
      it('Deletes an item', () => {
        cy.server()
        cy...
        cy.seedAndVisit()
    
        cy.get('.todo-list li')
          .first()
          .find('.destroy')
          .invoke('show')
          .click()
    
        cy.wait('@delete')
    
        cy.get('.todo-list li')
          .should('have.length', 3)
      })
    })

    We be DRY, we can create alias for DOM element:

    cy.get('.todo-list li')
      .as('list')
    cy.get('@list')
      .first()
      .find('.destroy')
      .invoke('show')
      .click()
    
    cy.wait('@delete')
    
    cy.get('@list')
      .should('have.length', 3)

    Test Variations of a Feature in Cypress with a data-driven Test

    Many applications have features that can be used with slight variations. Instead of maintaining multiple tests with nearly identical code, we can take advantage of the JavaScript runtime and use normal data structures and plain old JavaScript to test and make assertions for multiple interactions in a single test.

    describe('Footer', () => {
      it('Filters todos', () => {
        const filters = [
          {link: 'Active', expectedLength: 2},
          {link: 'Completed', expectedLength: 2},
          {link: 'All', expectedLength: 4}
        ]
        cy.seedAndVisit('fixture:mixed_todos')
    
        cy.wrap(filters)
          .each(filters => {
            cy.contains(filter.link).click()
    
            cy.get('.todo-list li').should('have.length', filter.expectedLength)
          })
    
      })
    })
  • 相关阅读:
    java学习-String上的操作
    java日常-String/StringBuilder/StringBuffer
    CentOS配置ip、修改主机名、重启
    java日常-新导入项目出现Java compiler level does not match the version of the installed java project facet问题处理
    MySql-Left join/right join/inner join-区别
    MySql-流程函数
    07—mybatis注解配置一
    06—mybatis缓存机制
    05—动态sql
    04—mybatis的关联映射
  • 原文地址:https://www.cnblogs.com/Answer1215/p/11396506.html
Copyright © 2011-2022 走看看