Cypress.Commands.add() - Build an Automation Script

Create and use a custom Cypress command to login

Preconditions (2)

Step 1: Open the login page at '/login'

Step 2: Use the custom command 'login' with username 'testuser' and password 'Test@1234'

Step 3: Verify that the URL changes to '/dashboard' after login

Step 4: Verify that the page contains a welcome message with text 'Welcome, testuser!'

✅ Expected Result: User is successfully logged in using the custom command, redirected to '/dashboard', and sees the welcome message

Automation Requirements - Cypress

Assertions Needed:

URL should be '/dashboard' after login

Page should contain text 'Welcome, testuser!'

Best Practices:

Define custom commands in cypress/support/commands.js

Use Cypress.Commands.add() to create reusable commands

Use cy.visit() and cy.get() with proper selectors

Use assertions with cy.url().should() and cy.contains().should()

Avoid hardcoded waits; rely on Cypress automatic waits

Automated Solution

Cypress

/// <reference types="cypress" />

// cypress/support/commands.js
Cypress.Commands.add('login', (username, password) => {
  cy.visit('/login');
  cy.get('input[name="username"]').type(username);
  cy.get('input[name="password"]').type(password);
  cy.get('button[type="submit"]').click();
});

// cypress/e2e/login_spec.js
describe('Login using custom command', () => {
  it('should login successfully and show welcome message', () => {
    cy.login('testuser', 'Test@1234');
    cy.url().should('include', '/dashboard');
    cy.contains('Welcome, testuser!').should('be.visible');
  });
});

The Cypress.Commands.add() function is used to create a custom command named login. This command visits the login page, fills in the username and password fields, and clicks the submit button.

In the test file, we call cy.login('testuser', 'Test@1234') to perform the login steps. Then, we assert that the URL includes /dashboard to confirm navigation after login. Finally, we check that the welcome message with the username is visible on the page.

This approach keeps the test clean and reusable by encapsulating login steps in a custom command.

Common Mistakes - 3 Pitfalls

Defining the custom command inside the test file instead of support/commands.js

Using hardcoded waits like cy.wait(5000) after clicking login

{'mistake': "Using incorrect selectors like cy.get('#username') when the input has name attribute", 'why_bad': 'Selectors may not match the actual elements, causing tests to fail.', 'correct_approach': 'Use accurate and stable selectors such as input[name="username"] or data-cy attributes.'}

Bonus Challenge

Now add data-driven testing with 3 different username and password combinations using the custom login command

Show Hint

Practice

1. What is the main purpose of Cypress.Commands.add() in Cypress testing?

easy

A. To configure browser settings

B. To add new test cases automatically

C. To create reusable custom commands for cleaner test code

D. To generate test reports

Solution

1. Step 1: Understand the function of Cypress.Commands.add()

   This method allows you to define your own commands that you can reuse in tests.

2. Step 2: Identify the benefit of reusable commands

   Reusable commands help keep test code clean and avoid repetition.

3. Final Answer:

   To create reusable custom commands for cleaner test code -> Option C

4. Quick Check:

   Reusable commands = Cleaner code [OK]

Hint: Remember: add() creates custom commands you can reuse [OK]

Common Mistakes:

• Thinking it adds test cases automatically
• Confusing it with test report generation
• Assuming it changes browser settings

2. Which of the following is the correct syntax to add a custom command named login in Cypress?

easy

A. Cypress.Commands.create('login', () => { /* code */ })

B. Cypress.addCommand('login', () => { /* code */ })

C. Commands.add('login', () => { /* code */ })

D. Cypress.Commands.add('login', () => { /* code */ })

Solution

1. Step 1: Recall the correct method name

   The correct method to add commands is Cypress.Commands.add().

2. Step 2: Check the syntax format

   The first argument is the command name as a string, the second is a function.

3. Final Answer:

   Cypress.Commands.add('login', () => { /* code */ }) -> Option D

4. Quick Check:

   Correct method and syntax = Cypress.Commands.add('login', () => { /* code */ }) [OK]

Hint: Use Cypress.Commands.add('name', function) always [OK]

Common Mistakes:

• Using Cypress.addCommand instead of Commands.add
• Omitting Cypress.Commands prefix
• Using create instead of add

3. Given the code below, what will be the output when cy.login() is called in a test?

 Cypress.Commands.add('login', (username, password) => {
  cy.get('#user').type(username)
  cy.get('#pass').type(password)
  cy.get('#submit').click()
})

// In test
cy.login('user1', 'pass1')

medium

A. Types 'user1' in #user, 'pass1' in #pass, then clicks #submit

B. Throws an error because login needs no parameters

C. Clicks #submit without typing anything

D. Types 'user1' in #pass and 'pass1' in #user

Solution

1. Step 1: Analyze the custom command parameters

   The command takes username and password and types them into respective fields.

2. Step 2: Follow the command actions

   It types username into '#user', password into '#pass', then clicks '#submit'.

3. Final Answer:

   Types 'user1' in #user, 'pass1' in #pass, then clicks #submit -> Option A

4. Quick Check:

   Parameters map to correct fields = Types 'user1' in #user, 'pass1' in #pass, then clicks #submit [OK]

Hint: Match parameters to fields carefully [OK]

Common Mistakes:

• Assuming no parameters are needed
• Mixing up username and password fields
• Ignoring the click action

4. Identify the error in the following custom command definition:

 Cypress.Commands.add('clickButton', () => {
  cy.get('#button')
  cy.click()
})

medium

A. Missing chaining of click() to cy.get()

B. Wrong command name, should be clickbutton

C. Should use cy.find() instead of cy.get()

D. No error, code is correct

Solution

1. Step 1: Review the command chaining

   cy.get('#button') returns an element, but cy.click() is called separately, not chained.

2. Step 2: Understand correct chaining

   Click should be chained to the element: cy.get('#button').click().

3. Final Answer:

   Missing chaining of click() to cy.get() -> Option A

4. Quick Check:

   Method chaining required = Missing chaining of click() to cy.get() [OK]

Hint: Always chain commands like cy.get(...).click() [OK]

Common Mistakes:

• Calling cy.click() separately
• Changing command name unnecessarily
• Using cy.find() instead of cy.get() without reason

5. You want to create a custom command fillForm that fills multiple fields and submits a form. Which approach correctly uses Cypress.Commands.add() to accept an object with field values and perform the actions?

hard

A. Cypress.Commands.add('fillForm', () => {
cy.get('#name').type(name)
cy.get('#email').type(email)
cy.get('#submit').click()
})

B. Cypress.Commands.add('fillForm', (data) => {
cy.get('#name').type(data.name)
cy.get('#email').type(data.email)
cy.get('#submit').click()
})

C. Cypress.Commands.add('fillForm', (name, email) => {
cy.get('#name').type(name)
cy.get('#email').type(email)
cy.get('#submit').click()
})

D. Cypress.Commands.add('fillForm', (data) => {
cy.get('#name').type(data[0])
cy.get('#email').type(data[1])
cy.get('#submit').click()
})

Solution

1. Step 1: Understand parameter passing

   Using a single object parameter data with named properties is clear and flexible.

2. Step 2: Check usage of object properties

   Accessing data.name and data.email matches the object keys.

3. Final Answer:

   Cypress.Commands.add('fillForm', (data) => { cy.get('#name').type(data.name) cy.get('#email').type(data.email) cy.get('#submit').click() }) -> Option B

4. Quick Check:

   Object parameter with named fields = Cypress.Commands.add('fillForm', (data) => { cy.get('#name').type(data.name) cy.get('#email').type(data.email) cy.get('#submit').click() }) [OK]

Hint: Pass one object with named fields for clarity [OK]

Common Mistakes:

• Using undefined variables without parameters
• Passing multiple parameters instead of one object
• Accessing object fields by index instead of name