[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)
      })

  })
})