Environment Configuration and data management.

Kishor Munot
5 min readApr 14, 2024

--

Environment Configuration in java-script automation tools

Hello Readers,

Whenever we choose any automation tool for our application framework, we have to decide how we are going to handle our multiple environments in application and by looking at the topic of the blog, you must have understood what we are going to talk about today. In automation we run our tests in multiple environments because running our automated tests in different environments ensures that our application is working without any manual effort from the team. We can keep our main environment on the same page and if we encounter a issue on the production environment we will have time to focus on the problem while solving the problem.

Why good environments are crucial for successful automation

A stable test automation environment offers several benefits. To start with, it ensures that automated tests run accurately and produce reliable results. It helps identify bugs, defects, or errors in the software early on, preventing them from reaching production. A stable test environment is a crucial component of a continuous integration (CI) process, because it allows for the automation of testing in each build cycle, providing immediate feedback on the quality of code changes.

Due to a number of circumstances, managing test data might be difficult. These include the complexity of data dependencies, data privacy concerns, the need for data masking or obfuscation, and the requirement for creating and maintaining diverse datasets. Additionally, test data must be generated, refreshed, and synchronized with different test environments as per the testing requirements. To guarantee the effectiveness and efficiency of automated testing methods, these obstacles must be overcome.

How to set up environment configuration in cypress

You might be using the cypress.json or a cypress.env.json file where your baseURL and environment variables are.Whenever you want to run your automated tests on staging or pre-production, you have to update the data and it’s a tedious task when you have to do it every time.

Let’s discuss how to configure our folderstructure in cypress framework.

Potential project hierarchy:

- ProjectFolder
-- cypress
-- fixtures
---- development.json
---- stage.json
---- production.json
----- environments.js
-- integration
--- specs
-- plugins
-- support
- package.json
- node.modules
- cypress.config.js

In the above folder structure of my framework I have created different JSON files for different environments and made centralized in environment.js

Lets example of my stag.js below where I am driving the data into the scripts for staging environments.

{
"appUrl": "https://testing.testqa.stage-org.net/",
"username": "fnanwani@org.com",
"password": "Q2XHy&7w",
"adminusername": "bwilson@org.com",
"adminpassword": "8@FdNE8j",

"firstNoticeDate" : "2024-04-15",
"firstNoticeofLoss" : "2024-04-12",
"dateOFLoss" : "2024-04-14",
"dateStatuteofLimitation" : "2024-04-20",
"practiceArea" : "Cyber Liability",
"stateName" : "Arkansas",
"countryName" : "Boone County",
"comparativeFault" :["Modified Comparative Fault (50% Bar Rule)","Modified Comparative Fault (51% Bar Rule)","Pure Comparative Fault","Pure Contributory Negligence","Slight/Gross Negligence Comparative Fault"]
}

You need to create JSON data like I created above for each environment. then you have to import this environment.js file in your tests and then you can drive your data from the respective Json on the respective environment.

How to centralize the data in environment.js

const FIXTURES = {
production: 'production',
staging: 'stag',
development: 'development'
};

export const CURRENT_FIXTURE = FIXTURES.staging;

You need to create one centerline configuration in environment.js so whenever you want to execute the tests on different environment you need to update the environment details only.

import { CURRENT_FIXTURE } from "../../../fixture/environments";

const data_json = require('../../../org-qa/fixture/data.json');

let environment_json = "";
if (CURRENT_FIXTURE == "production") {
environment_json = require('../../../fixture/production.json')
}
else {
environment_json = require('../../../fixture/stag.json')
}

You need to handle all environments through if-else statement and then you can use the data with environment_json in your script. You can also do this using a command file, or you can put login.js in your framework and add configuration so that your configuration is executed whenever login is executed.

scripts": {
"cy:open": "cypress open",
"cy:development": "cypress open --env fileConfig=development",
"cy:stage": "cypress open --env fileConfig=stage",
"cy:production": "cypress open --env fileConfig=production"
},
const data_json = require('../../../org-qa/fixture/data.json');let environment_json = "";
if (CURRENT_FIXTURE == "production") {
environment_json = require('../../../fixture/production.json')
}
else {
environment_json = require('../../../fixture/stag.json')
}

CI-CD Configration

Dynamically Switching Configuration Files, CI/CD

This is namely for when you need to run tests on the pipeline across different environments. Unfortunately, this is not something that I can publicly demonstrate, especially as it may not particularly apply to the CI/CD service that you use. However, the objective is to:

  1. Have environment variable values for each environment persisted in the pipeline/CI files which have the exact same value as the name of the config file stored in the Cypress project.
  2. Fetch and pass these values down to a Cypress environment variable called fileConfig. To do this, you need add a prefix of CYPRESS_ to the environment variable. Cypress will automatically look for environment variables that have a prefix of CYPRESS_, more on Cypress environment variables here.
  3. Ultimately, what you want, is to set the fileConfig environment variable to the required value. So if your test suite is about to run on Development, you need to set CYPRESS_fileConfig = “development”. Once again, the getConfigurationbyFile function will read the value of this variable and use it to determine which environment configuration file to use. Once your build is deployed to Stage, you want to do the same but have the value of fileConfig be stage, which will run the Cypress configuration specified in the stage.json file.
  4. Alternatively, you can setup another Node script which is solely used in the pipeline and execute that script with an argument when you run Cypress in the pipeline.

Benefits of handle test environments and manage data well

  • Improved test coverage and accuracy
  • Reduced false positives and negatives
  • Increased automation efficiency
  • Time and cost savings

Conclusion

Whether you need to configure your tests to run on each environment depends on your confidence in these tests and how much value they add by running on all environments. It might slow down your time to market, feedback loop and so on. It might also be completely overkill. This is up to yourself and the team you work with to decide, but the ability to very easily have Cypress run against Stage or Production on your machine locally without needing to adjust the set configs or baseURL’s is definitely great. Adopt a data-centric approach where test data is treated as a valuable asset. Define data requirements and identify suitable sources for acquiring or generating test data.

I hope this has been useful, thanks for reading!

Applaud the story will definitely be a great thought!!!😊

I’d like to hear your thoughts and if you have anything to share that would be wonderful for the community.

Thank you.. 😊

--

--