TypeScript support for custom commands in Cypress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a custom Cypress command with TypeScript

What will be the output in the Cypress test runner console after running this test code with the custom command?

Cypress

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

Cypress.Commands.add('login', (email, password) => {
  cy.get('#email').type(email);
  cy.get('#password').type(password);
  cy.get('#submit').click();
  return cy.url();
});

describe('Login Test', () => {
  it('should navigate to dashboard after login', () => {
    cy.login('[e-mail]', 'pass123').then(url => {
      cy.log(url);
    });
  });
});

A Logs the URL string of the page after clicking submit, e.g., 'https://app.example.com/dashboard'

B Logs undefined because the custom command does not return a value

C Throws a TypeScript error due to missing return type in the custom command

D Logs the Cypress chainable object instead of the URL string

💡 Hint

Check what the custom command returns and how the .then() callback receives it.

The custom command returns cy.url(), which yields the current URL string. The .then() callback receives this string and logs it. The TypeScript declaration ensures the command is recognized with correct parameters and return type.

❓ assertion

intermediate

Correct TypeScript assertion for a custom command result

Given a custom command that returns a user object, which assertion correctly checks the user's email property in TypeScript?

Cypress

declare namespace Cypress {
  interface Chainable {
    getUser(): Chainable<{ email: string; id: number }>;
  }
}

Cypress.Commands.add('getUser', () => {
  return cy.wrap({ email: '[e-mail]', id: 42 });
});

cy.getUser().should( /* Which assertion? */ );

A user => expect(user.email).toBe('[e-mail]')

B user => expect(user).to.have.property('email', '[e-mail]')

C user => expect(user.email).to.equal('[e-mail]')

D user => expect(user['email']).equals('[e-mail]')

💡 Hint

Use the correct Chai assertion syntax supported by Cypress.

Option B uses the correct Chai assertion syntax with .to.have.property() and .equal() to check the email property value. Option B is close but .to.equal() is not used as a function inside should(). Option B uses Jest syntax (.toBe) which is invalid here. Option B uses .equals() without .to, which is incorrect.

🔧 Debug

advanced

Debugging TypeScript error in custom command declaration

Why does this TypeScript error occur when adding a custom command? Error: Property 'fillForm' does not exist on type 'Chainable'.

Cypress

Cypress.Commands.add('fillForm', (name: string, age: number) => {
  cy.get('#name').type(name);
  cy.get('#age').type(age.toString());
});

// Usage
cy.fillForm('Alice', 30);

// TypeScript declaration missing

A Because the custom command 'fillForm' was added but not declared in Cypress.Chainable interface

B Because the command implementation has a syntax error in the arrow function

C Because the parameters types are incorrect and cause a type mismatch

D Because Cypress.Commands.add cannot add commands with multiple parameters

💡 Hint

Check if the TypeScript interface was extended to include the new command.

TypeScript requires extending the Cypress.Chainable interface to declare new custom commands. Without this declaration, TypeScript does not recognize 'fillForm' as a valid method on cy.

🧠 Conceptual

advanced

Understanding TypeScript declaration merging for Cypress commands

Which statement best describes how TypeScript supports adding custom commands in Cypress?

A You create a new interface with the same name as Cypress.Chainable and export it to override the original.

B You add JSDoc comments above the command implementation to inform TypeScript about the new command.

C You extend the Cypress.Chainable interface inside a declare namespace block to add method signatures for your commands.

D You must modify the Cypress source code to add new commands to the Chainable interface.

💡 Hint

Think about how TypeScript merges declarations from multiple files.

TypeScript supports declaration merging, so you extend existing interfaces by redeclaring them inside a declare namespace block. This way, your custom commands become recognized as part of Cypress.Chainable.

❓ framework

expert

TypeScript typing for custom command returning a typed promise

You want to create a custom Cypress command 'fetchUser' that returns a Promise resolving to a User object with properties 'id' (number) and 'name' (string). How should you declare it in TypeScript to ensure proper typing and chaining?

A

declare namespace Cypress {
  interface Chainable {
    fetchUser(): Chainable<Promise<{ id: number; name: string }>>;
  }
}

B

declare namespace Cypress {
  interface Chainable {
    fetchUser(): Promise<{ id: number; name: string }>;
  }
}

C

declare namespace Cypress {
  interface Chainable {
    fetchUser(): Chainable<void>;
  }
}

D

declare namespace Cypress {
  interface Chainable {
    fetchUser(): Chainable<{ id: number; name: string }>;
  }
}

💡 Hint

Remember Cypress commands always return Chainable wrapping the yielded value, not a raw Promise.

Cypress commands return Chainable wrapping the yielded value, not a raw Promise. Declaring fetchUser() as returning Chainable<{ id: number; name: string }> correctly types the command's yield. Option D wraps a Promise inside Chainable which is incorrect. Option D returns a raw Promise, breaking Cypress chaining. Option D loses the typed return value.

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