TypeScript support for custom commands in Cypress - Build an Automation Script

Add and use a custom Cypress command with TypeScript support

Preconditions (3)

Step 1: Create a custom command named 'login' that accepts username and password

Step 2: Implement the 'login' command to fill username and password fields and click the login button

Step 3: Add TypeScript declaration to extend Cypress namespace with the 'login' command

Step 4: Use the 'login' command in a test to log in with valid credentials

Step 5: Verify that after login, the URL contains '/dashboard'

✅ Expected Result: The test runs successfully using the custom 'login' command with TypeScript support, and the assertion confirms the URL contains '/dashboard'

Automation Requirements - Cypress with TypeScript

Assertions Needed:

Verify URL contains '/dashboard' after login

Best Practices:

Use Cypress.Commands.add to define custom commands

Extend Cypress namespace in a .d.ts file for TypeScript support

Use explicit selectors with data-cy attributes

Use async/await or Cypress chaining properly

Keep test code clean and readable

Automated Solution

Cypress

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

// cypress/support/commands.ts
Cypress.Commands.add('login', (username: string, password: string) => {
  cy.get('[data-cy=username]').clear().type(username);
  cy.get('[data-cy=password]').clear().type(password);
  cy.get('[data-cy=login-button]').click();
});

// cypress/support/index.d.ts
// This file adds TypeScript support for the custom command

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

declare namespace Cypress {
  interface Chainable {
    /**
     * Custom command to login
     * @example cy.login('user1', 'pass123')
     */
    login(username: string, password: string): Chainable<void>;
  }
}

// cypress/e2e/login.cy.ts

describe('Login Test with Custom Command', () => {
  beforeEach(() => {
    cy.visit('/login');
  });

  it('logs in using custom command and verifies dashboard URL', () => {
    cy.login('testuser', 'TestPass123!');
    cy.url().should('include', '/dashboard');
  });
});

The code defines a custom Cypress command named login in commands.ts. It uses cy.get with data-cy attributes to find username, password fields, and the login button, then performs typing and clicking.

In index.d.ts, the Cypress namespace is extended to add TypeScript support for the login command. This allows TypeScript to recognize cy.login() with proper parameter types.

The test file login.cy.ts visits the login page, uses the custom login command with sample credentials, and asserts that the URL contains /dashboard after login.

This setup ensures type safety, code reuse, and clear test steps.

Common Mistakes - 5 Pitfalls

{'mistake': 'Not extending Cypress namespace in a .d.ts file', 'why_bad': "TypeScript will show errors when using the custom command because it doesn't know about it.", 'correct_approach': 'Create or update a declaration file to extend Cypress.Chainable interface with the custom command signature.'}

{'mistake': "Using generic selectors like '.input' or '#username' instead of data-cy attributes", 'why_bad': 'Selectors can break easily if UI changes, making tests flaky.', 'correct_approach': 'Use stable selectors like data-cy attributes dedicated for testing.'}

{'mistake': 'Defining the custom command inside the test file instead of support/commands.ts', 'why_bad': "Commands won't be globally available and code reuse is limited.", 'correct_approach': 'Define custom commands in support/commands.ts so they load automatically.'}

Not clearing input fields before typing in the login command

Using incorrect Cypress command chaining or mixing async/await incorrectly

Bonus Challenge

Now add data-driven testing to run the login test with 3 different username and password combinations

Show Hint

Practice

1. What is the main benefit of adding TypeScript support for custom commands in Cypress?

easy

A. It makes tests run faster by optimizing command execution.

B. It provides type checking and better editor autocomplete for custom commands.

C. It automatically generates test reports for custom commands.

D. It allows running tests on multiple browsers simultaneously.

Solution

1. Step 1: Understand TypeScript role in Cypress

   TypeScript adds static type checking and editor support to catch errors early.

2. Step 2: Identify benefit for custom commands

   Typing custom commands improves autocomplete and prevents mistakes when using them.

3. Final Answer:

   It provides type checking and better editor autocomplete for custom commands. -> Option B

4. Quick Check:

   TypeScript support = type checking + autocomplete [OK]

Hint: TypeScript helps catch errors before running tests [OK]

Common Mistakes:

• Confusing TypeScript support with test speed improvements
• Thinking it auto-generates reports
• Believing it enables multi-browser runs

2. Which is the correct way to declare a custom command with TypeScript support in Cypress?

easy

A. namespace Cypress { interface myCommand { Chainable(): void } }

B. interface Cypress { Chainable { myCommand(): void } }

C. declare interface Cypress { myCommand(): void }

D. declare namespace Cypress { interface Chainable { myCommand(): Chainable<void> } }

Solution

1. Step 1: Recall TypeScript declaration syntax for Cypress commands

   Custom commands are declared inside the Cypress namespace extending Chainable interface.

2. Step 2: Match correct syntax

   declare namespace Cypress { interface Chainable { myCommand(): Chainable<void> } } correctly uses 'declare namespace Cypress' and extends 'Chainable' with 'myCommand'.

3. Final Answer:

   declare namespace Cypress { interface Chainable { myCommand(): Chainable<void> } } -> Option D

4. Quick Check:

   Namespace + Chainable interface = correct declaration [OK]

Hint: Custom commands extend Cypress.Chainable interface inside namespace [OK]

Common Mistakes:

• Missing 'declare' keyword
• Incorrect interface or namespace nesting
• Placing method outside Chainable interface

3. Given this TypeScript declaration for a custom command:

declare namespace Cypress {
  interface Chainable {
    login(email: string, password: string): Chainable<void>
  }
}

What is the correct way to use this login command in a test?

medium

A. cy.login(['[e-mail]', 'pass123'])

B. cy.login(email: '[e-mail]', password: 'pass123')

C. cy.login('[e-mail]', 'pass123')

D. cy.login()

Solution

1. Step 1: Understand method signature

   The login command takes two string arguments: email and password.

2. Step 2: Match correct usage syntax

   cy.login('[e-mail]', 'pass123') calls login with two string arguments in order, matching the declaration.

3. Final Answer:

   cy.login('[e-mail]', 'pass123') -> Option C

4. Quick Check:

   Method call with two string args = correct usage [OK]

Hint: Pass arguments as ordered parameters, not as object or array [OK]

Common Mistakes:

• Using named parameters syntax (not valid in JS calls)
• Passing arguments as array instead of separate params
• Calling without required arguments

4. You wrote this custom command declaration:

declare namespace Cypress {
  interface Chainable {
    clickButton(): void
  }
}

But when you use cy.clickButton() in your test, TypeScript shows an error. What is the problem?

medium

A. The return type should be Chainable<void>, not void.

B. The method name cannot be clickButton.

C. Custom commands must be declared outside the Cypress namespace.

D. You forgot to import Cypress in the test file.

Solution

1. Step 1: Check return type for custom commands

   Custom commands should return Chainable<T> to allow chaining in Cypress.

2. Step 2: Identify mismatch causing TypeScript error

   Returning void breaks chaining and causes TypeScript to complain.

3. Final Answer:

   The return type should be Chainable<void>, not void. -> Option A

4. Quick Check:

   Custom commands must return Chainable for chaining [OK]

Hint: Custom commands return Chainable, not void [OK]

Common Mistakes:

• Using void return type instead of Chainable
• Declaring commands outside Cypress namespace
• Assuming method names are restricted

5. You want to create a custom command fillForm that accepts an object with optional name and email fields. How should you declare it in TypeScript to support chaining and optional properties?

hard

A. declare namespace Cypress { interface Chainable { fillForm(data: { name?: string; email?: string }): Chainable<void> } }

B. declare namespace Cypress { interface Chainable { fillForm(data: { name: string; email: string }): void } }

C. declare namespace Cypress { interface Chainable { fillForm(data?: { name: string; email: string }): Chainable<void> } }

D. declare namespace Cypress { interface Chainable { fillForm(data: { name: string; email?: string }): Chainable<string> } }

Solution

1. Step 1: Define optional properties correctly

   Use question marks (?) to mark properties as optional in the data object.

2. Step 2: Ensure return type supports chaining

   Return type must be Chainable<void> to allow chaining in Cypress tests.

3. Final Answer:

   declare namespace Cypress { interface Chainable { fillForm(data: { name?: string; email?: string }): Chainable<void> } } -> Option A

4. Quick Check:

   Optional props + Chainable return = correct declaration [OK]

Hint: Use '?' for optional props and Chainable<void> return [OK]

Common Mistakes:

• Forgetting '?' for optional properties
• Using void return type instead of Chainable
• Returning wrong Chainable generic type