Organizations generally have their test strategies well defined for running e2e automation regression tests. Ideally, the e2e automation suites are triggered/executed before a PR merge or even on a commit.
However, there are times when there is a need to execute your automated tests in different environments, eg:
A feature branch - To regression test the feature before it is ready to be merged to your main branch
Dev/Staging - To run critical path or smoke tests to have that additional confidence. To test integrations with external apps or products
Production - Few run regressions post-production deployment. This should be a hard NO (why not —> this is a separate topic in itself!)
Now, for you to execute your e2e tests across environments there would be some obvious variables that differ based on environments which we know as environment variables.
Test configurations as environment variables
There are some test config values that change based on conditions or environments. To know how to set these environment variables, you can refer to Cypress documentation
What can be environment-based variables?
Application base URL
Backend API URL
Authentication tokens
External App’s secret keys
How to access variable values based on environment?
We would never want to manually change the test environment variable values based on where we want to execute our tests (i.e. local, dev, or qa/staging). Instead, these values should be seeded in our tests dynamically. How can this be achieved?
We would try to create the same number of config files based on the number of environments where we want to execute the test runs. eg cypress-dev.json, cypress-qa.json, etc
If we consider the list of variables mentioned in the previous section, most of those except for the base URL are also part of the front end application’s .env config file
So, can we reuse the application .env files instead of creating and maintaining additional config files like cypress-dev.json, cypress-qa.json?
How to dynamically setup Cypress config values from app .env
Prerequisite: Cypress version 10+ as we will look at the cypress config file which is based on version 10
Suppose your application has .env files based on different environments as shown below
2. Some of the test configurations that we want to have in the .env files. eg below is the .env file for local execution.
Similarly, you can set corresponding values in the other environment based files (.env.dev, .env.qa, etc)
3. How to read the variable values from .env files and set them as Cypress config or env variables
In the above code snippet, you would need to
Import dotenv package
In the setupNodeEvents callback, you can access the variables through process.env and set them accordingly in your cypress config or the cypress env objects
Return this updated config in setupNodeEvents
Now, verify if the required Cypress configurations are set
Run npx cypress open
Click on your preferred browser
Go to Settings
You will see baseURL set as
The other environment variables are set as part of env
3. We would now want to read values from dynamically picked .env files based on the environment where we want to run the Cypress tests
We can create separate command line scripts in package.json for each of the environments and pass a config value say E2E_ENV as shown below
You would need to install cross-env package, to pass config values like E2E_ENV
In the above code snippet, on the first line, we are now passing the path value to the config. The code .env${process.env.E2E_ENV} will create the required file path based on the E2E_ENV value. eg for qa it will load .env.qa. When we do not pass any value for E2E_ENV as shown in “test” script in package.json file, by default .env file will be picked.
Verify if the required Cypress configurations are set -
you can run npm run test-qa
On the Cypress settings page you would see
baseURL is now set to the qa one
Similarly, other variables would have the qa specific values as expected
Advantages of this approach
Avoid creating additional Cypress specific config files
Reuse any env variables already defined in the application env file