At Ensolvers, we use Cypress for writing automated interaction/integration tests - i.e. tests that simulate a real user interacting with the UI and perform asserts to ensure that it behaves as expected. These types of tests can run in what is called “Headless Mode”, meaning that they will be executed without the need for a UI (User Interface) environment. In that case, tests will still have a web UI to load the app and execute the interactions (basically, a running DOM model in a browser context), but that UI will not require a graphical interface to work. This allows running interaction tests in a traditional Docker container, which is a huge leap in automation since it means that we can integrate the test running on CI/CD pipelines directly.
We've already discussed how to build Cypress tests in this article. Assuming that we have a test suite already set up and running, there are different commands that Cypress works with, but when we are building tests and trying them out (as exampled in that article) we mostly use the Graphic Interface with the open command
If we don’t want to see every step of the tests while they are executed, instead we can use the run Cypress command
This will search all the tests that are present inside the cypress/e2e folder and start running them without opening the browser GUI, by default start testing in headless mode, but it can also specify it by adding the --headless flag like this:
When running headless Cypress will look up for all the tests contained in the e2e folder and start running them in a queue and using the Cypress native browser Electron. Now, let's see how we can use this in the context of an CI/CD pipeline.
In the example we are going to show here, we are going to use AWS CodeBuild. Long story short, AWS CodeBuild allows you to define in a YAML file called buildspec.yaml, all the information needed to run the pipeline: container, environment, commands, etc. In the code below we show a full example we are going to describe
Before anything, in the install phase we ensure that we export information about current commit like author, SHA hash, remote, etc. in environment variables. The names and values of these variables will be stored when the final test run report is generated.
As the build is performed in a linux standard build instance (assuming no dependencies), in order for Cypress to run, we need to install them first as shown in the code snippet below. In the future, to save computing time we can build a custom Docker image with those instances pre-built.
When all the dependencies are installed, we then move forward and install cypress npm dependencies, verifying the cypress installation and its information.
Once everything is installed and set up, inside the build step we run the script responsible for executing all the e2e tests, which is defined inside package.json:
As we've mentioned earlier, we intend to upload the results of the test run and the videos and screenshots of failing tests, to do that we included the --record flag and also in the Codebuild configuration environment variables we included the CYPRESS_RECORD_KEY to be able to connect with the right Cypress Cloud account.
We also set the --browser flag to chromium and, even though it's redundant, because cypress executes tests in headless mode by default, we add the --headless flag to ensure the tests are executed without using a GUI.
Once all the tests finish, the results will be uploaded and you or anyone in your team will be able to check them, and access videos or screenshots in case some test fails.
Cypress is a very powerful tool for integration testing. Having it set up in a CI/CD pipeline allows us to have a constant status of the application quality and behavior at any point in the development process. Overall, including Cypress in a dedicated pipeline build to test a living instance of your application, is pretty straight forward by following the guide in this article.
