What is a wide configuration? What should the configuration be like? And why is it important to dedicate time to this?
In the article, we will try to answer these questions, using the following technologies as examples: Cypress as a testing framework and GitHub Actions as a CI/CD tool.
So, imagine you've decided to buy a car. Do you want to add any options? Perhaps automatic transmission. Winter tires. Climate control, or something else?
A testing framework without a well-thought-out configuration is like a car without options. It can get you to your destination, but the journey is unlikely to be comfortable.
Under the 'wide configuration,' we understand the ability to pass the most important options and/or arguments to your testing framework.
Explaining in detail we must be able to easily run the tests in any %put the item from the list below% we want.
The following article won't contain examples of Safari usage because its configuration will be defined in a separate article.
In our example, we will build out the configuration using a default Cypress Project. You can apply this config to your project or check out the final configuration in github.
Let’s start with a test example, look at this simple test below. The URL used in the test can be easily replaced with your project environment's URL.
To accomplish this, Cypress utilizes environment variables. You can find detailed information about this here.
example.cy.js file:
In order to easily provide environment-related data as we desire, we need to start with adding dotenv and cross-env package dependencies. Then add a script to open cypress with a specified environment.
package.json file:
Now create .env.dev file with url env variable:
Then change cypress.config.ts configuration:
The final part is to update the test itself:
From this moment, we simplify variables management for cases when we jump from one environment to another, everything we need is just to pass the correct .env file (or set of environment variables) to Cypress.
Up until this moment, we have been using the default or selected browser.
The next step is to be able to use the chosen browser with preferred options. To make this happen:
In result we can run any pre-defined browser and pass custom arguments.
.webp)
Defining resolutions is a bit more complex… So, before we begin with the code let’s agree on some criteria:
The task seems to be quite simple since we can just pass viewport options:
But in this case, we won’t handle such important things as:
To handle all advanced options we start with resolution objects creation.
As a result of the previous setup, we can run the tests in the chosen environment, using the preferred browser with the desired resolution and capabilities. Now time to integrate it to CI/CD so everyone benefits from the tests.
After configuration is applied, we can start the test run, just select your options from the list in boxes:
And check the result:
Today, we've reviewed how to build a testing framework that is flexible enough to accommodate client needs such as custom environments, browsers, options, and resolutions.
We've also integrated everything into CI, so not only the development or automation QA team can benefit from our solution, but everyone on the team can run the test suites with just a few clicks.
Check out this test project in our GitHub repository and apply useful configuration parts to your project. Good luck and see you later!
Our team will contact you with 3 business days.
