如何在Cypress中编写自定义命令？自定义hover命令无效问题排查

The core issue here is how you're interacting with the subject in your command. When using prevSubject: "element", the subject parameter passed to your callback is a jQuery object, not a Cypress command chain. Calling subject.trigger("mouseenter") uses jQuery's native trigger method, which doesn't integrate with Cypress's asynchronous command queue. This means Cypress doesn't wait for the hover action to properly complete, and it doesn't trigger the same browser events that Cypress's own trigger command does—hence why your inline version works but the custom command doesn't.

To fix this, you need to wrap the jQuery subject back into a Cypress chain using cy.wrap(), then call Cypress's trigger command on it. Here's the corrected command:

Cypress.Commands.add("hover", { prevSubject: "element" }, (subject) => {
  return cy.wrap(subject).trigger("mouseenter");
});

Now when you call cy.get('[test-id="my-test-id"]').hover(), it will behave exactly like the inline trigger call, as it’s using Cypress’s properly synchronized command flow.

Custom commands are a great way to reuse repetitive actions across your tests. Here’s a breakdown of key concepts and best practices to follow:

1. Where to Define Commands #

By default, Cypress loads custom commands from cypress/support/commands.js. For larger projects, you can split commands into organized files (e.g., cypress/support/commands/hover.js) and import them into commands.js to keep your codebase clean.

2. Basic Command Structure #

The syntax for adding a custom command is:

Cypress.Commands.add(commandName, options, callbackFunction);

Key Options: #

• prevSubject: Controls whether the command accepts a previous subject from the chain:
  • "element": The command requires a DOM element subject (like your hover command).
  • "optional": The command can run with or without a subject.
  • "always": The command always expects a subject.
• If your command doesn’t need a subject, you can omit the options object and just pass the callback.

3. Handling Asynchronous Actions #

Cypress commands are asynchronous, so your custom command should return a Cypress chain (e.g., cy.wrap(), cy.get(), cy.request()) to ensure Cypress waits for it to complete before moving to the next step in your test.

Example 1: No Subject Needed (Login Command) #

Cypress.Commands.add("login", (username, password) => {
  cy.visit("/login");
  cy.get('[test-id="username-input"]').type(username);
  cy.get('[test-id="password-input"]').type(password);
  cy.get('[test-id="submit-button"]').click();
  // Return a chain to confirm login success
  return cy.get('[test-id="welcome-message"]');
});

// Usage: cy.login("testuser", "password123");

Example 2: With Optional Subject (Clear Input) #

Cypress.Commands.add("clearInput", { prevSubject: "optional" }, (subject) => {
  if (subject) {
    // Clear the provided input element
    return cy.wrap(subject).clear();
  } else {
    // Clear all visible input elements
    return cy.get("input:visible").clear();
  }
});

// Usage: cy.clearInput(); or cy.get('[test-id="email-input"]').clearInput();

4. Best Practices #

• Keep commands focused: Each command should handle one specific action (like your hover command, which only triggers mouseenter).
• Return chains: Always return a Cypress chain so tests can continue chaining assertions or other commands.
• Add TypeScript definitions (if applicable): For TypeScript projects, define types for your custom commands in cypress/support/index.d.ts to get autocompletion and type safety.
• Test your commands: Treat custom commands like any other code—write tests to verify they work as expected across different scenarios.

内容的提问来源于stack exchange，提问作者DWilches