cypress.config.js settings - Framework Patterns

Framework Mode - cypress.config.js settings

Folder Structure

cypress/
├── e2e/
│   ├── login.cy.js
│   ├── dashboard.cy.js
│   └── userProfile.cy.js
├── fixtures/
│   └── userData.json
├── support/
│   ├── commands.js
│   └── e2e.js
cypress.config.js
package.json

Test Framework Layers

• Configuration Layer: cypress.config.js - central place for environment settings, base URLs, browser options, timeouts.
• Test Layer: cypress/e2e/ - contains test files with .cy.js suffix, each file holds related test cases.
• Support Layer: cypress/support/ - reusable commands and setup code loaded before tests.
• Fixtures Layer: cypress/fixtures/ - static test data like JSON files for consistent test inputs.

Configuration Patterns

The cypress.config.js file manages settings for different environments and browsers.

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'https://staging.example.com',
    specPattern: 'cypress/e2e/**/*.cy.js',
    supportFile: 'cypress/support/e2e.js',
    setupNodeEvents(on, config) {
      // Add plugins or event listeners here
    },
    env: {
      username: 'testuser',
      password: 'securePass123'
    },
    defaultCommandTimeout: 8000,
    pageLoadTimeout: 60000,
    retries: {
      runMode: 2,
      openMode: 0
    },
    viewportWidth: 1280,
    viewportHeight: 720,
    video: true,
    screenshotsFolder: 'cypress/screenshots',
    videosFolder: 'cypress/videos'
  }
})

Key points:

• baseUrl sets the main URL for tests, easy to switch for dev, staging, prod.
• env stores sensitive or variable data like usernames, passwords.
• retries helps tests rerun on failure to reduce flaky results.
• setupNodeEvents is for plugins or custom event handling.
• Timeouts control how long Cypress waits for commands or page loads.

Test Reporting and CI/CD Integration

Cypress integrates well with CI/CD pipelines and reporting tools.

• Use cypress run --reporter junit or mochawesome for detailed test reports.
• Configure reporters in cypress.config.js or via CLI.
• Store screenshots and videos on test failure for debugging.
• Integrate with CI tools like GitHub Actions, Jenkins, GitLab CI to run tests automatically on code changes.
• Use environment variables in CI to switch config (e.g., baseUrl, credentials).

Best Practices for cypress.config.js Settings

• Centralize configuration: Keep all environment and test settings in cypress.config.js for easy maintenance.
• Use environment variables: Avoid hardcoding sensitive data; use env or CI secrets.
• Set sensible timeouts: Adjust command and page load timeouts to balance speed and reliability.
• Enable retries: Configure retries to reduce flaky test failures without hiding real issues.
• Organize test files: Use clear naming and folder structure for easy test discovery and maintenance.

Self Check

Where in this framework structure would you add a new environment configuration for production with a different baseUrl and credentials?

Key Result

Centralize all Cypress test settings in cypress.config.js for easy environment and behavior management.

Practice

1. What is the main purpose of the cypress.config.js file in a Cypress project?

easy

A. To set configuration options like base URL and test locations for Cypress tests

B. To write the actual test cases for Cypress

C. To install Cypress dependencies

D. To run Cypress tests manually from the command line

Solution

1. Step 1: Understand the role of cypress.config.js

   This file is used to configure how Cypress runs tests, including settings like base URL and test file paths.

2. Step 2: Differentiate from other files

   Test cases are written in separate test files, not in the config file. Installation and running commands happen outside this file.

3. Final Answer:

   To set configuration options like base URL and test locations for Cypress tests -> Option A

4. Quick Check:

   Config file sets options = D [OK]

Hint: Config file sets test environment and paths [OK]

Common Mistakes:

• Confusing config file with test files
• Thinking config installs Cypress
• Believing config runs tests manually

2. Which of the following is the correct way to export the Cypress configuration using defineConfig in cypress.config.js?

easy

A. module.exports = { baseUrl: 'http://localhost:3000' }

B. export const config = { baseUrl: 'http://localhost:3000' }

C. defineConfig({ baseUrl: 'http://localhost:3000' })

D. export default defineConfig({ e2e: { baseUrl: 'http://localhost:3000' } })

Solution

1. Step 1: Recall the modern Cypress config syntax

   Since Cypress 10+, the config file uses defineConfig and exports it as default with ES module syntax.

2. Step 2: Check the correct structure

   The e2e object wraps settings like baseUrl. export default defineConfig({ e2e: { baseUrl: 'http://localhost:3000' } }) matches this pattern exactly.

3. Final Answer:

   export default defineConfig({ e2e: { baseUrl: 'http://localhost:3000' } }) -> Option D

4. Quick Check:

   Use defineConfig with export default = B [OK]

Hint: Use export default defineConfig({ e2e: { ... } }) [OK]

Common Mistakes:

• Forgetting to wrap settings inside e2e object
• Using CommonJS export instead of ES module
• Not using defineConfig function

3. Given this cypress.config.js snippet, what will be the base URL used during test runs?

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'https://example.com',
    specPattern: 'cypress/e2e/**/*.cy.js'
  }
})

medium

A. http://localhost:3000

B. https://example.com

C. cypress/e2e/**/*.cy.js

D. No base URL is set

Solution

1. Step 1: Identify the baseUrl property in config

   The config sets baseUrl to 'https://example.com' inside the e2e object.

2. Step 2: Understand baseUrl usage

   This URL is used as the root for all relative URLs in tests, so it will be 'https://example.com'.

3. Final Answer:

   https://example.com -> Option B

4. Quick Check:

   baseUrl set to https://example.com = C [OK]

Hint: Look for baseUrl inside e2e object [OK]

Common Mistakes:

• Confusing specPattern with baseUrl
• Assuming default localhost URL
• Missing that baseUrl is inside e2e

4. You wrote this cypress.config.js but Cypress throws an error when running tests:

import { defineConfig } from 'cypress'

export default {
  e2e: {
    baseUrl: 'http://localhost:8080'
  }
}

What is the likely cause of the error?

medium

A. Using export default instead of module.exports

B. baseUrl must be outside the e2e object

C. Missing call to defineConfig wrapping the config object

D. baseUrl value must be an IP address

Solution

1. Step 1: Check the export syntax

   The config is exported as a plain object, but Cypress expects the config wrapped in defineConfig().

2. Step 2: Understand Cypress config requirements

   Without defineConfig, Cypress cannot properly parse the config, causing errors.

3. Final Answer:

   Missing call to defineConfig wrapping the config object -> Option C

4. Quick Check:

   Always wrap config in defineConfig() = A [OK]

Hint: Always wrap config object with defineConfig() [OK]

Common Mistakes:

• Placing baseUrl outside e2e
• Confusing export default with CommonJS
• Thinking baseUrl must be IP address

5. You want to set a custom environment variable API_KEY in cypress.config.js so it can be accessed in your tests. Which is the correct way to add it inside the config?

hard

A. export default defineConfig({ e2e: { env: { API_KEY: '12345' } } })

B. export default defineConfig({ env: { API_KEY: '12345' } })

C. export default defineConfig({ e2e: { baseUrl: 'http://localhost', API_KEY: '12345' } })

D. export default defineConfig({ e2e: { environment: { API_KEY: '12345' } } })

Solution

1. Step 1: Locate where environment variables go

   Environment variables for e2e tests go inside the env object nested within the e2e config.

2. Step 2: Verify correct property names

   The key must be env, not environment, and it must be inside e2e.

3. Final Answer:

   export default defineConfig({ e2e: { env: { API_KEY: '12345' } } }) -> Option A

4. Quick Check:

   Use e2e.env for env vars = A [OK]

Hint: Put env vars inside e2e.env object [OK]

Common Mistakes:

• Placing env outside e2e
• Using wrong key name like environment
• Adding env vars directly under e2e without env object