Why element selection drives interaction in Cypress - Framework Benefits

Framework Mode - Why element selection drives interaction

Folder Structure

  cypress/
  ├── e2e/                  # Test files
  │   ├── login.cy.js       # Example test
  │   └── dashboard.cy.js
  ├── fixtures/             # Test data files (JSON)
  │   └── users.json
  ├── support/              # Custom commands and utilities
  │   ├── commands.js       # Custom Cypress commands
  │   └── index.js          # Support file loaded before tests
  └── cypress.config.js     # Cypress configuration file
  

Test Framework Layers

• Test Layer (e2e/): Contains test scripts that describe user scenarios and interactions.
• Element Selection Layer: Uses Cypress selectors (cy.get, cy.find) to locate elements precisely before interacting.
• Support Layer (support/): Houses reusable commands and helper functions to abstract common interactions.
• Fixtures Layer (fixtures/): Stores test data to separate data from test logic.
• Configuration Layer: Manages environment settings, base URLs, and browser options in cypress.config.js.

Why Element Selection Drives Interaction: Before Cypress can click, type, or check an element, it must find it reliably. Good selectors ensure tests interact with the right elements, making tests stable and meaningful.

Configuration Patterns

• Environment Variables: Use cypress.env.json or env in cypress.config.js to store URLs, credentials, and flags.
• Browser Selection: Configure browsers via CLI or config file to run tests in Chrome, Firefox, or Edge.
• Base URL: Set baseUrl in cypress.config.js to avoid repeating full URLs in tests.
• Timeouts: Adjust default command timeouts to wait for elements to appear before interaction.

  // cypress.config.js example
  export default {
    e2e: {
      baseUrl: 'https://example.com',
      env: {
        username: 'testuser',
        password: 'password123'
      },
      defaultCommandTimeout: 8000
    }
  }
  

Test Reporting and CI/CD Integration

• Built-in Reporter: Cypress provides a clear test runner UI showing passed/failed tests and screenshots on failure.
• Custom Reporters: Integrate with Mocha reporters or use plugins like mochawesome for HTML reports.
• CI/CD Integration: Run Cypress tests in pipelines (GitHub Actions, Jenkins) with headless browsers and upload reports/artifacts.
• Video Recording: Enable video recording of test runs for debugging failed interactions.

Best Practices

1. Use Data Attributes for Selectors: Prefer data-cy or data-test attributes to select elements, avoiding brittle selectors like classes or IDs that change.
2. Keep Selectors Specific and Stable: Select elements uniquely to avoid false matches and flaky tests.
3. Abstract Repeated Selections: Create custom commands or functions in support/commands.js to reuse element selectors and interactions.
4. Wait for Elements Properly: Use Cypress automatic retries and explicit assertions to ensure elements are ready before interacting.
5. Separate Test Data: Use fixtures to keep test data apart from selectors and test logic for easier maintenance.

Self Check

Where in this framework structure would you add a new custom command to select a login button by its data-cy attribute?

Key Result

Reliable element selection is the foundation for stable and meaningful Cypress test interactions.