Child commands in Cypress - Framework Patterns

Framework Mode - Child commands

Folder Structure of a Cypress Test Project

  cypress/
  ├── e2e/                  # Test specs (test cases)
  │   ├── login.cy.js       # Example test file
  │   └── dashboard.cy.js
  ├── support/              # Custom commands and reusable code
  │   ├── commands.js       # Custom child commands defined here
  │   ├── e2e.js            # Support file loaded before tests
  │   └── index.js          # Entry point for support files
  ├── fixtures/             # Test data files (JSON, etc.)
  │   └── user.json
  └── cypress.config.js     # Cypress configuration file
  

Test Framework Layers in Cypress with Child Commands

• Test Specs (e2e/): Contains test files that use child commands to interact with page elements.
• Support Layer (support/commands.js): Defines custom child commands that extend Cypress commands for reusable actions.
• Fixtures: Holds test data used by tests and commands.
• Configuration: Manages environment settings and browser options.
• Utilities: Helper functions can be added in support or separate utility files for complex logic.

Configuration Patterns for Child Commands in Cypress

Use cypress.config.js to set base URLs, environment variables, and browser settings.

Example environment config:

  module.exports = {
    e2e: {
      baseUrl: 'https://example.com',
      env: {
        username: 'testuser',
        password: 'password123'
      },
      setupNodeEvents(on, config) {
        // implement node event listeners here
      }
    }
  }
  

Access environment variables inside child commands via Cypress.env().

Test Reporting and CI/CD Integration

• Use built-in Cypress Dashboard or plugins like mochawesome for detailed reports.
• Configure reporters in cypress.config.js to generate HTML or JSON reports.
• Integrate Cypress tests in CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI) to run tests automatically on code changes.
• Use cypress run --reporter mochawesome to generate reports during CI runs.

Best Practices for Using Child Commands in Cypress

1. Keep child commands small and focused: Each command should do one clear action for easy reuse.
2. Use chaining properly: Return Cypress chainables from child commands to allow chaining in tests.
3. Use descriptive names: Name child commands clearly to describe their purpose.
4. Access environment variables safely: Use Cypress.env() inside commands for sensitive data.
5. Document commands: Add comments to explain what each child command does.

Self Check

Where would you add a new child command for logging in a user in this Cypress framework structure?

Key Result

Organize Cypress tests with custom child commands in support/commands.js for reusable, chainable actions.

Practice

1. What does the .find() command do in Cypress testing?

easy

A. It clicks on an element.

B. It types text into an input field.

C. It waits for a page to load.

D. It locates child elements inside a parent element.

Solution

1. Step 1: Understand the purpose of .find()

   The .find() command is used to search for elements inside another element, meaning it looks for child elements.

2. Step 2: Compare with other commands

   Commands like .click(), .type(), and .wait() perform actions or wait, but do not locate child elements.

3. Final Answer:

   It locates child elements inside a parent element. -> Option D

4. Quick Check:

   .find() locates children = B [OK]

Hint: Remember: .find() searches inside a parent element [OK]

Common Mistakes:

• Confusing .find() with .click() or .type()
• Thinking .find() waits for elements
• Using .find() without a parent element

2. Which of the following is the correct syntax to find a button inside a div with class container using Cypress?

easy

A. cy.get('.container').find('button')

B. cy.find('.container').get('button')

C. cy.get('button').find('.container')

D. cy.find('button').get('.container')

Solution

1. Step 1: Understand chaining commands in Cypress

   First, cy.get() selects the parent element. Then, .find() locates child elements inside it.

2. Step 2: Analyze each option

   cy.get('.container').find('button') correctly uses cy.get('.container') to select the parent, then .find('button') to find the child button. Other options misuse the order or commands.

3. Final Answer:

   cy.get('.container').find('button') -> Option A

4. Quick Check:

   Parent first with get(), then child with find() = A [OK]

Hint: Use cy.get() first, then .find() for child elements [OK]

Common Mistakes:

• Swapping .get() and .find() order
• Using .find() without cy.get() first
• Selecting child before parent

3. What will the following Cypress code select?

cy.get('ul.menu').find('li.active').should('have.length', 2)

medium

A. It selects all li elements inside ul.menu with class active and checks there are 2.

B. It selects 2 ul elements with class menu.

C. It clicks on the first li.active element.

D. It types '2' into the ul.menu element.

Solution

1. Step 1: Understand the selector chain

   cy.get('ul.menu') selects the ul element with class menu. Then .find('li.active') finds li children with class active.

2. Step 2: Understand the assertion

   .should('have.length', 2) asserts that exactly 2 such li.active elements exist inside the ul.menu.

3. Final Answer:

   It selects all li elements inside ul.menu with class active and checks there are 2. -> Option A

4. Quick Check:

   Find children with class and check count = A [OK]

Hint: Find children, then assert count with .should('have.length') [OK]

Common Mistakes:

• Confusing parent and child selectors
• Thinking it clicks or types instead of asserting
• Misreading the assertion purpose

4. Identify the error in this Cypress code snippet:

cy.find('.list').get('li').should('have.length', 3)

medium

A. There is no error; the code is correct.

B. The selector '.list' is invalid.

C. The order of commands is incorrect; .get() should come before .find().

D. The assertion .should('have.length', 3) is not valid.

Solution

1. Step 1: Check command order

   cy.find() is not a valid starting command. cy.get() must be used first to select the parent element.

2. Step 2: Correct usage

   The correct order is cy.get('.list').find('li') to find li children inside the element with class list.

3. Final Answer:

   The order of commands is incorrect; .get() should come before .find(). -> Option C

4. Quick Check:

   Use cy.get() first, then .find() = D [OK]

Hint: Always start with cy.get() before .find() [OK]

Common Mistakes:

• Starting with .find() instead of cy.get()
• Assuming .find() works alone
• Ignoring command chaining rules

5. You want to verify that a form with id login contains exactly 3 input fields that are visible. Which Cypress code correctly uses child commands to do this?

hard

A. cy.find('#login').get('input:visible').should('have.length', 3)

B. cy.get('#login').find('input:visible').should('have.length', 3)

C. cy.get('#login').find('input').should('have.length', 3).and('be.visible')

D. cy.get('input:visible').find('#login').should('have.length', 3)

Solution

1. Step 1: Select the parent form element

   Use cy.get('#login') to select the form with id 'login'.

2. Step 2: Find visible input children and assert count

   Use .find('input:visible') to get visible input fields inside the form, then assert there are exactly 3 with .should('have.length', 3).

3. Final Answer:

   cy.get('#login').find('input:visible').should('have.length', 3) -> Option B

4. Quick Check:

   Parent get(), then find visible inputs, then check length = C [OK]

Hint: Chain get() then find(':visible') before asserting length [OK]

Common Mistakes:

• Using .find() before cy.get()
• Checking visibility after length assertion
• Incorrect selector order