Negative assertions (not) in Cypress - Framework Patterns

Framework Mode - Negative assertions (not)

Folder Structure

  cypress/
  ├── e2e/
  │   ├── login.spec.js       # Test files with negative assertions
  │   ├── dashboard.spec.js
  │   └── ...
  ├── fixtures/               # Test data files
  │   └── users.json
  ├── support/
  │   ├── commands.js         # Custom commands including negative assertion helpers
  │   ├── e2e.js              # Global setup for tests
  │   └── index.js
  └── cypress.config.js       # Cypress configuration file
  

Test Framework Layers

• Test Layer (e2e/): Contains test scripts using negative assertions like should('not.exist') or should('not.have.text').
• Support Layer (support/): Holds reusable commands and utilities, e.g., custom negative assertion commands for clarity and reuse.
• Fixtures Layer (fixtures/): Stores test data used in tests to simulate negative scenarios.
• Configuration (cypress.config.js): Defines environment settings, browser options, and base URLs for tests.

Configuration Patterns

Use cypress.config.js to manage environments and browsers:

  import { defineConfig } from 'cypress'

  export default defineConfig({
    e2e: {
      baseUrl: 'https://example.com',
      env: {
        username: 'testuser',
        password: 'password123'
      },
      setupNodeEvents(on, config) {
        // event listeners
      },
      retries: 1
    }
  })
  

Access credentials and environment variables in tests via Cypress.env(). This helps test negative cases like invalid login.

Test Reporting and CI/CD Integration

• Use built-in Cypress Dashboard or plugins like mochawesome for detailed reports showing passed and failed negative assertions.
• Integrate Cypress tests in CI/CD pipelines (GitHub Actions, Jenkins) to run tests automatically on code changes.
• Failing negative assertions (e.g., element unexpectedly present) will cause test failure, clearly reported in logs and dashboards.

Best Practices

1. Use explicit negative assertions like should('not.exist') or should('not.contain') to clearly express what should not happen.
2. Keep tests independent; negative assertions should not rely on previous test state.
3. Use custom commands in support/commands.js to simplify repeated negative checks.
4. Use fixtures to provide invalid or unexpected data for negative test scenarios.
5. Run tests in multiple browsers and environments to catch environment-specific negative cases.

Self Check

Where in this folder structure would you add a new custom command to check that a button is not visible?

Key Result

Organize Cypress tests with clear folder layers, use explicit negative assertions, and integrate reporting for reliable test automation.