Sunčica Kojić

When we set up Cypress E2E tests for our project, it became clear early on that they needed to run before every production deployment. That meant one thing: CI/CD.

Next thing I know, DevOps is talking about setting up CI/CD for the tests. The conversation went something like this:

DevOps: “Who will set up CI/CD for Cypress tests?” Me: “Can I try?” DevOps: “Great, welcome to the DevOps team.” Me: “… Help? “

On a serious note, when I got the go-ahead, it was time for a little research on how to set up the action. All the articles on the web say the same thing: you have something called jobs, steps, and boom — the action is ready.

It all sounds simple enough in theory. But when you come from a QA background and have little to no knowledge of the DevOps world, that’s not very helpful.

Clearly, “boom - the action is ready” was missing a few steps for folks like me. So naturally, I did what anyone would do in my position - I turned to the DevOps team for help.

The best advice I can give you - the advice I got from the DevOps team - is this: everything you do to set up, launch the project, and run tests locally on your machine, you need to do essentially the same within your GitHub Action. Once I followed this approach, everything became much clearer.

Since you’re here, I’m guessing you already know Cypress and GitHub Actions and simply want the solution, so let’s skip definitions and jump straight into it.


Cypress + GitHub Actions: What Makes It Work

Implementation means getting your hands dirty with the actual setup. I’ll break down every step, making sure you understand what’s happening and why.

After that, you’ll see an example workflow file to help you visualize how to automate your Cypress tests in GitHub Actions. Let’s dive in!


Step 1. Creating a workflow file

GitHub Actions uses YAML files to define workflows. To create your first workflow:

 * In the root of your project, create a folder called .github (if it doesn’t already exist).
 * Inside that folder, create another folder named workflows (if it doesn’t already exist).
 * Inside .github/workflows/, create a new file — you can name it something like run-cypress.yml.

Your final path should look like this:

your-project/
├── .github/
│   └── workflows/
│       └── run-cypress.yml


This is the file where your automated Cypress testing pipeline begins.


Step 2. Choosing the Right Trigger

Before our Cypress tests can run, something needs to tell GitHub Actions “Go”. That something is called a trigger - it defines when your CI workflow should start.

There are plenty of trigger options, but for test automation, only a select few are actually useful, such as - push, pull_request, workflow_dispatch, schedule, and optionally deployment_status. Let’s break them down.

Trigger: push

Runs the workflow when code is pushed to the repository.

Best for:

 * Running tests automatically whenever code is pushed to key branches like main or develop.

Use it to:

 * Automatically check that new code on key branches doesn’t break anything, verify hot-fixes or quick fixes pushed directly, and run tests on new version tags.

on:
  push:
    branches:                     
      - main                     # Automatically check that new code on key branches doesn’t break anything
      - develop                  # Same as above — check changes before merging to production
      - 'hotfix/*'               # Checking hotfixes or quick fixes pushed directly
    tags:                       
      - 'v*'                     # Running tests on new version tags (e.g., v1.0.0)


Trigger: pull_request

Runs the workflow when a pull request targets specific branches.

Best for:

 * Catching bugs before merging code into important branches.

Use it to:

 * Automatically run tests when a pull request is opened, updated, or reopened, ensure only working code is merged into specific branches, and block merges if tests fail using branch protection rules.

Note: Configuring branch protection rules happens in your GitHub repository settings.

on:
  pull_request:
    branches:          # Run tests when a PR targets these branches (opened or updated)
      - main
      - develop
      - 'release/*'


Trigger: workflow_dispatch

Runs the workflow manually when you trigger it via GitHub UI.

Best for:

 * Running tests on demand, whenever you want.

Use it to:

 * Rerun flaky or failing tests without pushing new code, manually test changes to your Cypress setup or pipeline, and run targeted test runs on demand.

on:
  workflow_dispatch:
    inputs:
      namespace:                          # Deployment namespace selection 
        description: 'Target namespace'   # Shown as prompt in GitHub Actions UI
        required: true                    # Must provide this input to trigger workflow
        default: 'development'            # Preselected default value in UI
        type: choice                      # Input type is a dropdown list
        options:                          # Allowed options for the namespace input
          - development
          - staging
          - production
      branch:                             # Git branch to run the tests or deployment on
        description: 'Test branch'        # Input prompt description shown in UI
        required: true                    # This input must be provided by the user
        type: string                      # Accepts any string (branch name)
             # Useful for running targeted test runs on demand



Trigger: schedule

Runs the workflow on a recurring cron schedule.

Best for:

 * Running regular automated tests to catch issues even without code changes.

Use it to:

 * Automatically run Cypress tests on a nightly, weekly, or custom schedule, verify that external services and APIs your app depends on are functioning correctly, and detect issues like expired credentials or unexpected changes before they affect users.

on:
  schedule:
    - cron: '0 3 * * *'       # Runs tests nightly at 3:00 AM UTC
    - cron: '0 0 * * 0'       # Runs tests weekly on Sundays at midnight UTC

Trigger: deployment_status

Runs the workflow after a deployment is completed.

Best for:

 * Running tests after the app goes live.

Use it to:

 * Automatically run smoke tests after a successful deployment to ensure the app works as expected for real users and to catch post-deployment issues like broken pages, bad configurations, or failing APIs.

on:
  deployment_status:
    types:
      - success    # Run this workflow only after a successful deployment




Step 3. - Defining Jobs for Cypress Setup

Once we’ve got our triggers in place, we need to tell GitHub Action what to actually do. That’s the job of… well, the job. Think of a job as a to-do list for your CI workflow - it installs what you need, starts the app, and finally runs your Cypress tests.

Let’s break down the main parts of a job and see how each step helps get your tests running smoothly.

#1
Each job runs on a specific runner — a machine where the steps execute. GitHub provides hosted runners like ubuntu-latest, windows-latest, and macos-latest, or you can use your own self-hosted runner.

jobs:
  cypress-run:               # This is the job name — you can name it anything                                   
    runs-on: ubuntu-latest


#2
When the runner is set up, we need to check out the repository so the workflow can access the project files.

    steps:
      - name: Checkout the code/repository 
        uses: actions/checkout@v4


#3
Following that, the runner prepares the Node.js environment to match the project settings for dependable test execution.

 - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20' 


#4
Then, dependencies are set up using the lockfile to avoid version mismatches.

   - name: Install dependencies
        run: npm ci



#5
These next steps launch your application and wait for it to become responsive before running tests. This is necessary when testing locally, but not required for deployed apps.

- name: Start the app
        run: npm run start &

- name: Wait for the app to be ready
        uses: jakejarvis/wait-action@v0.1.0
        with:
          url: '<http://localhost:3000>'
          timeout: 60
        # Waits up to 60 seconds until the app responds — prevents Cypress from running too early


#6
In this step, Cypress tests are triggered. If you’re testing locally, you need to start the app within the workflow (see step above) - but for deployed environments, simply point Cypress to the live URL.

- name: Run Cypress tests
  uses: cypress-io/github-action@v6
  with:
    start: false
    config: baseUrl=https://your-deployed-app.com  # Skip local app startup; run tests against live site



#7
The last step uploads screenshots and videos only if tests fail, which helps you debug directly in the GitHub UI. This step is optional and can be included if you want easier access to test artifacts.

name: Upload test artifacts (on failure)
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: cypress-artifacts
          path: |
            cypress/screenshots
            cypress/videos


With the core pieces in place, you now have a clear picture of how Cypress fits into your CI workflow.

Next, let’s bring it all together. Below is the complete YAML file that puts everything into action.

Quick tip: Cypress has an official GitHub Action on the Marketplace to help you set up and run tests easily.

name: Cypress test run

on:
  workflow_dispatch:
    inputs:
      namespace:
        description: "Namespace to run tests against"
        required: true
        default: development
        type: choice
        options:
          - development
          - staging
      branch:
        description: "Branch to checkout"
        required: true
        type: string
        default: main

jobs:
  run-tests:
    name: Cypress test run
    runs-on: self-hosted

    steps:
      # Print some helpful info about how and where the workflow is running
      - run: echo "🚀 This self-hosted job was automatically triggered by a ${{ github.event_name }} event on a ${{github.ref_name}}."
      - run: echo "🐧 This job is now running on a runner with name ${{ runner.name }} on ${{ runner.os }} server."

      - name: Checkout Repository
        uses: actions/checkout@v4
        with:
          ref: ${{ inputs.branch }}
          fetch-depth: 1

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20' 

      - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."

      - name: Cypress install
        id: cypress-install
        uses: cypress-io/github-action@v6
        with:
          runTests: false

      - name: Run Cypress Tests
        id: cypress-tests
        if: steps.cypress-install.outcome == 'success'
        uses: cypress-io/github-action@v6
        with:
          browser: electron
          headed: false
          config-file: cypress.config.js
          config: baseUrl=${{ github.event.inputs.namespace == 'staging' && '<https://staging.com>' || '<https://development.com>' }}
          record: false
        env:
           # Cypress and project-specific environment variables.
					 # These values are stored locally in a .env file during development,
					 # but are securely set as GitHub Secrets for use in this GitHub Action.
          CYPRESS_CACHE_FOLDER: ~/.cache/Cypress
          CYPRESS_AUTH_USERNAME: ${{ secrets.AUTH_USERNAME }}
          CYPRESS_AUTH_PASSWORD: ${{ secrets.AUTH_PASSWORD }}
          CYPRESS_ENV: ${{ github.event.inputs.namespace }} 

      - name: Outcome
        if: steps.cypress-tests.outcome == 'success'
        run: |
          echo "🎉 The job was a success!"



And that’s it. Your setup might not be identical, but this should get you 90% of the way there.


Closing the Loop with Cypress CI/CD

Setting up Cypress in CI isn’t as scary as it seems. The key is to replicate the way you run tests locally within your workflow, making sure the process stays consistent no matter where it runs.

The above examples lay out the basics to get you going, helping you avoid confusion and wasted time.

You’ll need to tweak it to match your project’s requirements - there’s no one-size-fits-all solution.

But once it’s ready, you’ll have reliable tests running on every change, keeping your deployments smooth.

From 'It Works on My Machine' to 'It Works in CI': Cypress in (GitHub) Action

Tired of manual test updates for different environments? Learn how to configure Cypress for scalable, multi-environment testing and speed up your QA process.

How to Configure Cypress for Multi-Environment Testing (Guide)

Tired of manually updating test configurations for different environments? Learn how to set up a maintainable, scalable Cypress configuration that your team will thank you for.


The Challenge of Environment Management in Cypress

As a QA engineer, you're likely familiar with this scenario: Your Cypress tests run perfectly in your local environment, but then something breaks in staging. Or perhaps you're managing multiple test suites across development, staging, and production environments, each with their own URLs, credentials, and API endpoints. Sound familiar?

While Cypress provides tools for managing different environments, turning these capabilities into a practical, maintainable configuration requires careful planning. Without the right approach, you might find yourself:

 * Constantly updating hardcoded URLs and credentials
 * Wrestling with merge conflicts from environment-specific changes
 * Struggling to maintain consistency across your CI/CD pipeline
 * Dealing with configuration drift between environments

In this guide (Part 1 of our two-part series), we'll cut through the complexity and show you exactly how to set up a robust Cypress configuration that scales across environments.

Part 2 will deal with additional challenges of testing multi-domain applications.

Let's start with environment configuration, from basic setups to production-grade solutions.


Managing cypress.config.js manually

Let’s look at a simple configuration file below.

For instance, to run tests in a local environment, we must specify a local baseUrl. Transitioning to development or staging requires manually adjusting this value, especially if the staging environment has unique settings, such as basic authentication.

//cypress.config.js

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    e2e: {
        setupNodeEvents() {},
        baseUrl: 'http://localhost:8000',
        // baseUrl: 'https://development.example.com',
        // baseUrl: 'https://staging.example.com',
        supportFile: 'cypress/support/e2e.js',
    },
});

Pros:

 * Quick and Flexible Setup — This method allows for easy setup and quick adjustments.

Cons:

 * Human Error — When configurations are changed manually, mistakes that affect the testing process can easily be made.
 * Merge Conflicts — When multiple team members make changes to the configuration, it can create conflicts that disrupt teamwork.
 * Limited CI/CD Effectiveness — Manual updates can reduce the effectiveness of CI/CD processes by introducing complications that make it harder to maintain smooth, efficient pipelines.
 * Increased Complexity in Testing — While they might seem like a quick fix, manual updates can make the testing process more complicated and less stable overall.

In conclusion, while manually updating configuration files may address immediate testing needs, it ultimately complicates the testing process and undermines stability. Adopting automated configuration management solutions is crucial for building a more robust and adaptable testing environment.


Using separate configuration files for each environment

Separate configuration files can be used to set up different environments in Cypress. For local testing, specify the baseUrl directly in cypress.config.js. To run tests on various environments, we create distinct configuration files in the project’s root directory.

For instance, in the staging environment, we create a file named cypress.staging.js that defines the baseUrl and other environment-specific variables. We do the same for development and production with their respective settings. If staging requires basic authentication, we include the necessary credentials in this configuration file.

//cypress.staging.js

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    e2e: {
        setupNodeEvents() {
        },
        supportFile: 'cypress/support/e2e.js',
        baseUrl: 'https://staging.example.com',
        auth: {
            username: 'your-username',
            password: 'your-password',
        },
    },
});

When the above configuration for each environment is set up, we need to add custom scripts in our package.json file.

//package.json 

"cy:open": "cypress open",
"cy:run": "cypress run",
"cy:run:staging": "cypress run --config-file cypress.staging.js",
"cy:open:staging": "cypress run --config-file cypress.staging.js",

Now you can switch environments by running yarn cy:staging:run or yarn cy:staging:open command in your terminal.

Pros:

 * Better Organization — Keeping configurations separate for each environment helps maintain clarity and organization.
 * Easy Environment Switching — You can quickly switch between different environments by referencing the right configuration file, which saves time and reduces the need for manual changes.
 * Consistent Test Execution — With environment-specific settings, tests are more likely to run consistently and as expected across different environments.
 * More Flexible — Having separate configuration files for each environment makes it easier to adapt to changes without affecting other setups.

Cons:

 * More Complexity — Managing multiple configuration files can make things more complicated, especially as the project grows.
 * Risk of Misconfigurations — The more configuration files there are, the greater the chance for misconfigurations, which can lead to unreliable tests.
 * Multiple File Maintenance — Keeping all configurations in sync and up-to-date can be time-consuming, particularly as the number of environments increases.
 * Lack of Clarity — With multiple files to keep track of, it can be hard to know which one to modify, increasing the risk of making mistakes.
 * Troubleshooting Complexity — When tests fail, having multiple configurations to check can make it more difficult to pinpoint the issue.

In summary, using separate configuration files for each Cypress environment improves clarity, enables easy switching between environments, and ensures consistent test execution.

However, this approach can also add complexity, raising the risk of misconfigurations and necessitating diligent maintenance. While it allows for tailored settings, careful management is crucial to avoid issues as the number of environments increases.


Managing environment configurations in a single Cypress configuration file

Running Cypress tests across multiple domains and environments introduced specific challenges, such as managing varying configurations, maintaining consistency across different setups, and ensuring seamless execution across domains.

Existing solutions couldn’t fully address these complexities, so we adjusted our approach to meet these unique demands by customizing our testing framework to ensure reliability, scalability, and reduced maintenance overhead.

The key to implementing this solution is creating a cypress.env.json file, which centralizes environment-specific variables like base URLs, API endpoints, and authentication credentials. This allows us to dynamically adjust the configuration for development, staging, or production tests.

For example, instead of hardcoding the base URL for each test suite, you can simply reference an environment variable that points to the correct URL for the active environment.

//cypressEnvConfig.json

const envConfig = {
  development: {
    default: "https://development.example.com",
  },
  staging: {
    default: "https://staging.example.com",
  },
  production: {
    default: "https://production.example.com",
  },
};
module.exports = { envConfig };

Next, in our configuration file cypress.config.json, we need to implement dynamic configuration based on the CYPRESS_ENV environment variable.

//cypress.config.js

const { defineConfig } = require('cypress');
const { envConfig } = require('./cypressEnvConfig');

module.exports = defineConfig({
    e2e: {
        setupNodeEvents(on, config) {
            const environment = process.env.CYPRESS_ENV || 'local';
            const currentEnvConfig = envConfig[environment];
            config.baseUrl = currentEnvConfig.dahefault;
            config.env.urls = currentEnvConfig;

            return config;
        },
        supportFile: 'cypress/support/e2e.js',
    },
});

Let's break down this setup. The setupNodeEvents function is pivotal in Cypress configuration, ensuring tests are properly set up based on the environment defined by the CYPRESS_ENV variable. If the variable is not specified, it defaults to local.

The function retrieves environment-specific settings from the cypressEnvConfig.json file, including baseURL, and updates the configuration accordingly.

The function then returns the modified config object, ensuring that Cypress tests are executed with the precise configuration tailored to the specified or default environment.

Next, each environment is managed through a dedicated run command that utilizes the CYPRESS_ENV variable to precisely configure the test execution environment.

//package.json
 	     
 	      "cy:open": "cypress open",
        "cy:run": "cypress run",
        "cy:open:development": "CYPRESS_ENV=development yarn cypress open",
        "cy:run:development": "CYPRESS_ENV=development yarn cypress run",
        "cy:open:staging": "CYPRESS_ENV=staging yarn cypress open",
        "cy:run:staging": "CYPRESS_ENV=staging yarn cypress run"

To use the centralized configuration from the cypress.env.json file in your test suite, access the environment variables with the Cypress.env() function. For instance, you can retrieve the default URL by using the following code:

//test.cy.js

const requestUrl = Cypress.env('urls').default;

Pros:

 * Single Source of Truth — By using a single file for environment variables, you avoid handling multiple configuration files, and keeping things organized.
 * Easy to Switch Environments — Environment variables allow dynamic switching, simplifying the process for different environments.
 * Reduced Risk of Errors — Referencing environment variables reduces the chance of accidentally running tests in the wrong environment.
 * Scalability — If you need to add a new environment, you only need to update one file, not create new ones for each environment.
 * Consistency — A single configuration file ensures uniform settings across all environments, reducing discrepancies and improving test reliability.
 * Simplified Maintenance — A single file is easier to maintain than multiple configuration files, reducing the potential for inconsistencies.

Cons:

 * Security Risks — Sensitive data in a single file (e.g., credentials) may expose risks if not secured properly.
 * Configuration Mistakes — Mistakes in the cypress.env.json file can affect all environments if not handled carefully.

This approach allows you to reference the correct URL based on the active environment without hardcoding any values in your tests.


Simplify Environment Management with a Unified Configuration Approach

Handling multiple environments in Cypress is essential for effective testing across various configurations. Relying on manual updates or separate settings can lead to mistakes and make things more complicated, but using one configuration with dynamic environment variables is a more efficient solution.

This method reduces errors and makes it easy to adapt to new environments. It also keeps things simple, so teams can focus on building strong tests and ensuring the app works properly during deployment.

Ultimately, this makes Cypress a powerful tool for end-to-end testing, helping create a faster and more reliable workflow as applications grow.

Continue reading the 2nd part of this series, where we’ll talk about managing multiple domains in Cypress. Just like with environments, testing across different domains can be tricky. But with the right approach, you can handle it easily and keep your tests running smoothly.

Are Your Cypress Tests a Configuration Mess?

Learn to test multiple domains in Cypress using cy.visit(), cy.origin(), and environment variables. Solve session, CORS, and configuration challenges.

How to Test Multiple Domains in Cypress: A Complete Guide

Your Cypress tests work great within a single domain, but what happens when your application spans multiple domains?

Whether you're dealing with microservices, third-party integrations, or localized versions of your site, testing across domains can quickly become complicated.


Why Multi-Domain Testing in Cypress Can Be Tricky

If you're a QA engineer working with modern web applications, you've likely encountered these scenarios:

 * Your tests break when crossing domain boundaries
 * Session management becomes unreliable between different domains
 * CORS issues keep popping up in your test runs
 * Your configuration becomes unwieldy when handling multiple domains

In Part 1 of this series, we covered how to set up Cypress for different environments. Now in Part 2, we'll tackle the specific challenges of testing applications that span multiple domains. You'll learn practical approaches using cy.visit(), cy.origin(), and environment variables to create a robust, maintainable test suite that works seamlessly across domains.

Let's explore the different solutions and find the right approach for your testing needs.


Simplifying Multi-Domain Tests with cy.visit()

When testing an application across multiple domains, Cypress's cy.visit() allows you to navigate to different URLs, ensuring consistent application behavior. This is particularly valuable for applications that interact with external services, APIs, or localized versions.

In the example below, cy.visit() is used in separate it blocks to load various domains within a Cypress test suite. Each test case interacts with a specific domain, performing assertions to validate functionality independently. This method facilitates multi-domain testing, ensuring consistent behavior across different websites within a single test file.

//test.cy.js


describe('Multi-Domain Testing with cy.visit()', () => {
  it('Testing functionality on https://example.eu', () => {
    cy.visit('https://example.eu');

   //Your tests here
  });

  it('Testing functionality on https://example.us', () => {
    cy.visit('https://example.us');

    //Your tests here
  });
});

Pros:

 * Simplified Test Writing — You can streamline the process of writing tests by managing domain navigation with a single command.
 * Early Issue Detection: — Helps identify domain-specific issues early in the testing phase.
 * Simplified Navigation — Enables easy transitions between domains in a single command.

Cons:

 * CORS Issues — Cross-origin requests can be blocked, causing functionality issues between domains.
 * Increased Complexity — Jumping between domains in tests can introduce more complexity, making tests harder to maintain.
 * Slower Test Execution — Multi-domain navigation can slow down test execution.
 * Harder Debugging — The added complexity can make pinpointing issues and debugging more challenging.
 * More Maintenance Effort— Any changes to the configuration might require updates across multiple test specs, increasing maintenance work.
 * Session Management Complexity — Managing authentication tokens and cookies across domains is challenging.

In conclusion, although cy.visit() simplifies multi-domain testing in Cypress, it’s important to consider the challenges that may emerge during the process.


How to Test Multiple Domains with cy.origin()

The cy.origin() command in Cypress is essential for testing applications that span multiple domains. This command enables you to run test commands within the context of different origins, making it particularly useful for applications with varied behaviors based on the domain accessed.

The example demonstrates how to use cy.origin() to run tests across two different domains: https://example.eu and https://example.us. Each block begins with cy.visit('/') to navigate to the root of the specified domain, allowing you to add test code to interact with elements on each site.

This approach ensures that tests remain isolated by domain, promoting clear and organized multi-origin testing.

//test.cy.js

describe('Multi-Domain Testing', () => {
  it('should navigate and perform actions on example.eu', () => {
    cy.origin('https://example.eu', () => {
      cy.visit('/');
      // your test code for the EU site
    });
  });

  it('should navigate and perform actions on example.us', () => {
    cy.origin('https://example.us', () => {
      cy.visit('/');
      // your test code for the US site
    });
  });

Pros:

 * Session Persistence — Maintains user sessions across different domains, ensuring seamless interactions.
 * Realistic Testing — Reflects real-world user behavior by allowing actions like logging in or retrieving user data without losing authentication.
 * Context-Specific Execution — Executes commands within the relevant domain's context, improving the precision and reliability of test results.

Cons:

 * Added Complexity — Each test block runs independently, which can make the overall test structure harder to follow and manage.
 * Debugging Difficulties — A more complex setup can make identifying and fixing issues more challenging.
 * Time-Consuming Updates — Requires individual updates across multiple test specs, increasing maintenance time and the risk of inconsistencies.

In summary, while cy.origin() in Cypress offers significant advantages for testing multi-domain applications, such as session persistence and context-specific execution, it also introduces complexities that can complicate the testing process and increase maintenance efforts. Careful consideration of these trade-offs is essential for effective multi-domain testing strategies.


Using Environment Variables to Manage Multiple Domains

After reviewing a few different approaches to multi-domain testing in Cypress, it becomes clear that managing different configurations is essential for ensuring accurate and efficient test execution. Cypress provides a straightforward way to handle this through environment variables. By using environment variables, you can control which domain or API your tests interact with, making it easier to manage various scenarios and requirements.

Setting Environment Variables

//cypress.env.json

const envConfig = {
  development: {
    DOMAIN_EU: "https://example.dev.eu",
    DOMAIN_US: "https://example.dev.us",
  },
  staging: {
    DOMAIN_EU: "https://example.staging.eu",
    DOMAIN_US: "https://example.staging.us",
  },
  production: {
    DOMAIN_EU: "https://example.eu",
    DOMAIN_US: "https://example.us",
  },
};

module.exports = { envConfig };

The above setup allows you to seamlessly connect specific domains with their respective environments, ensuring that your tests run against the correct URLs based on the active configuration. By managing both domains and environments together, you create a flexible and scalable testing framework that can easily adapt to changing requirements.

Once you have defined your environment variables, you can easily access them within your test cases. Here’s how to incorporate environment variables in your tests:

//test.cy.js

describe('Multi-Domain Testing with Environment Variables', () => {
  it('should navigate to the specified EU domain', () => {
    const domain = Cypress.env('DOMAIN_EU');
    cy.visit(domain);
    // your test code for the EU site
  });

  it('should navigate to the specified US domain', () => {
    const domain = Cypress.env('DOMAIN_US');
    cy.visit(domain);
    // your test code for the US site
  });
});

Pros:

 * Simplified Management — Environment variables allow a single location to manage URLs and API endpoints, simplifying updates and reducing hard-coded values in test scripts.
 * Easy Updates — Updating a value in the configuration file automatically reflects across all tests, saving time and making your tests more adaptable.
 * Reliable Testing — By reducing manual changes, you ensure more consistent and accurate test results across different environments.
 * Flexible Configurations — You can easily set up different environment variables for development, staging, and production, making it seamless to switch between environments.
 * CI/CD Friendly — CI/CD pipelines can easily integrate environment variables, ensuring consistent configurations across automated testing and deployment, which reduces the chances of environment-specific problems.
 * Version Control Friendly — Sensitive information (like API keys) can be stored in environment variables instead of being hard-coded, making it safer to use version control systems without exposing sensitive data.
 * Dynamic Configuration — Environment variables allow for runtime configuration changes, which can be useful for tests that require different setups based on varying conditions.

Cons:

 * Security Concerns — Sensitive data in environment variables can be at risk if not handled carefully, especially if it appears in logs or error messages.
 * Managing Complexity — As projects grow, managing a large number of environment variables can get tricky, requiring good organization and documentation.
 * Setup Dependencies — Tests may fail if the necessary environment variables are not set correctly, leading to potential issues in test execution.

Leveraging environment variables in Cypress provides a flexible and maintainable approach to managing multiple domains during testing. By centralizing your configurations and allowing for easy updates, you can enhance the efficiency of your testing process while minimizing errors associated with manual changes. This practice is especially valuable in multi-domain scenarios where different domains require unique settings.


What We Learned About Multi-Domain Testing with Cypress

In conclusion, effectively managing multiple domains in Cypress is crucial for ensuring a seamless user experience in modern web applications. A well-planned approach helps you overcome common challenges in multi-domain testing, such as handling session management, resolving CORS issues, and addressing the unique behaviors of different domains.

By applying the right strategies, you can achieve more reliable test execution across multiple domains, ultimately improving application quality and user satisfaction. Adopting these best practices will enable you to build robust applications that consistently meet user expectations and deliver dependable performance.

AuthorSunčica Kojić

Start a Project