Back to all blogposts

Continuous Integration for E2E tests (2/4): CircleCI configuration for test automation

Józef Szymala

Józef Szymala

QA Engineer

Being QA Engineer for over 4 years, I normally deliver the most effective tests which cover the most important scenarios. I have never had a chance to set up a Continuous Integration process. In most cases, my job was done once I prepared a command which can run the tests in headless with the use of Bitbucket, CircleCI or any other tool. However, during one of the projects I had to automate a process. Below, I’ll present you how I approached this task and how to configure CircleCI for test automation.

The scenarios I faced during the aforementioned project weren’t too complicated, so I managed to write down the tests swiftly. It was time I decided to check how CI works in practice. I wanted to experience how to deal with it – how difficult it is and if I can do it myself or if I rather need a hand of DevOps. In the previous part of the article, I focused on reporting with Cypress and Mochawesome. Today, we’ll take a closer look at automating E2E process with CircleCI. 

Jenkins? Not this time.

My first thought was to use Jenkins. It’s a pretty popular tool with multiple functions. Unfortunately, Jenkins is as popular as well-known for its coarse UI. I’ve experienced it a few times and that’s why I decided to use CircleCI instead. 

CircleCI – simple setup

Setting up CircleCI is straightforward. I started by creating an account on CircleCI website. You can use one of the available options, such as signing up with GitHub or Bitbucket. 

Using GitHub or Bitbucket is pretty useful because once you are logged in, you can see all the repositories from your GitHub/Bitbucket account in the CircleCI dashboard. After choosing a repository where tests need to be performed, you have to add a configuration file that is used by CircleCI.

To do it, you have to start by creating a new folder “.circleci” in your project. It must contain “config.yml” file. For more information about configuration, you can visit CircleCI official page.

What are orbs? As per official CircleCI website – “orbs define reusable commands, executors, and jobs so that commonly used pieces of configuration can be condensed into a single line of code.”

Description:

  • version: which version of CircleCI is used,
  • cypress: what orb you want to use,
  • cypress/run: it simply runs tests,
  • executor: it defines the Node version you use

Once you perform all the changes in a branch – you will notice the build starts running with your tests in CircleCI. If tests fail, you receive an immediate report with all the information about the test failure in your email.

CircleCI nightly run setup

If you need to configure the start of a build at a certain time (for example to verify tests every night) – I recommend using the configuration presented below.

Description:

  • nightly: in this place you can put any name which describes the time test need to be performed,
  • triggers: it is used to communicate to CircleCI that you need to plan a process with a certain flow,
  • schedule: it indicates that you plan/schedule the test,
  • cron: it is for defining the crone to set how your build is started (to generate a proper crone, I recommend using Crontab); it’s important to remember that CircleCI doesn’t accept */1 neither commas,
  • filters: it can be used to define processes, 
  • branches: it communicates CircleCI to use certain branches, 
  • master: it narrows the use of CircleCI to the use of branch master (you can define any existing branch).

You can wonder why section jobs is repeated twice. It’s because the first job will be always started after the newest changes. The other job will trigger the run of night tests. With .yml files, you need to remember the proper amount of spaces and tabs, because your CI tool may end up not performing your script.

CircleCI advanced setup with the artifacts

The last example I will present – starts your tests from Docker. Then, it will cache node_modules to save time and then, it will store the artifacts which are relevant for the test (such as reports described in the first part of this article or a folder with a video of the tests). 

You can check the full example on a repository in branch circle.ci

Definitions:

  • docker: it defines what image you use when using Cypress (in environment section you can define xterm – it helps you get coloured syntax in the terminal),
  • working_directory: it’s a place where your app and tests will be built 
  • checkout: it can perform checkout from your branch to a working directory, 
  • restore_cache, save_cache: https://circleci.com/docs/2.0/caching/#using-a-lock-file those commands can save your time during caching node_modules if your packages haven’t been changed during the project,
  • run: this section runs the command for testing (it was defined in the previous part of the article in the section about mochareporter
  • store_artifacts: you can provide the paths for a folder which you need to store for further verification.

Let’s take a look at the application itself.

CircleCI – application overview

Below, you can see a screenshot from the CircleCI application. Similarly to the reports – everything is segregated and clear. The information you can find in the section jobs is:

  • who released a build,
  • a commit name,
  • the time duration of a build,
  • when a build was released,
  • a build status.

Once you open a certain build, you can see the detailed information about it. You can go through all the steps which have been performed. If any failure appeared – you can easily verify what was wrong in your CI. Whether was it caused by wrong configuration or tests finished with an incorrect result.

It’s also worth digging into the artifacts section. You can find there full access to your folders with reports and video recordings. CircleCI advantage is also the fact you don’t have to download files – you can simply take a look through them in a browser.

What’s the deal with CircleCI configuration for test automation?

Thanks to the configuration above – you can be sure that your tests will start every time you need them. They will store all the necessary data and will be set for a certain time. In one of the next parts of this article, I will focus on a similar configuration for Bitbucket Pipelines and plugging into Slack reporter. Thanks to that – you can be notified whether your tests turned red or green as early as your first coffee and Slack scrolling in the morning. Stay tuned!

***

If you want to learn more about CircleCI, I recommend visiting the websites below.

Cypress documentation for CI 

Exemplary project on the branch circle.ci 

Interviews
CTO vs Status Quo

Find the exact rules Tech Managers used to organize IT & deliver solutions the Board praised.

Read here

The Software House is promoting EU projects and driving innovation with the support of EU funds

What would you like to do?

    Your personal data will be processed in order to handle your question, and their administrator will be The Software House sp. z o.o. with its registered office in Gliwice. Other information regarding the processing of personal data, including information on your rights, can be found in our Privacy Policy.

    This site is protected by reCAPTCHA and the Google
    Privacy Policy and Terms of Service apply.

    We regard the TSH team as co-founders in our business. The entire team from The Software House has invested an incredible amount of time to truly understand our business, our users and their needs.

    Eyass Shakrah

    Co-Founder of Pet Media Group

    Thanks

    Thank you for your inquiry!

    We'll be back to you shortly to discuss your needs in more detail.