Automated API Testing with Cypress

Following on from my recent post detailing why you should be focusing on API testing (if you aren’t already). I wanted to show an example of a testing tool that I’m sure many people are interested in using for their automated UI testing needs and detail how to use it to perform automated API testing.

Why use Cypress?

If your tech stack is dependent on JavaScript in the front-end with a framework like React or Vue. And you’re making use of it in the back-end layer with a service like Firebase. Then using a JavaScript end-to-end testing tool might be something that you may want to consider.

This will allow you to collaborate with developers (if needed), share code and gain a holistic understanding of the complete application from the front to the back.

Other libraries and tools are available and I really recommend that you never use a tool because you think it’s the one that you should be using. A tool is something that enables its user to be productive in an area. Instead of worrying about the tool you are using. Might I suggest that you instead focus on the problem you are trying to solve.

You might have the shiniest and best hammer that money can buy. But if you can’t hit a nail with it. It’s kinda worthless.

That’s not to say that you should only learn to use tools that could be useful or you can be used in only a narrow set of use cases. I recently tried using Cypress to make a web scraper and even though it kinda worked. It was obvious it’s a job that better suited other tools and programming languages, like Python.

Learning to use tools and processes outside your existing realm of knowledge has a side effect of you learning when it makes sense to use them.

Setting up your project

The prerequisites for following along are that node.js in setup and working on your machine. You can download node here, or use package managers like homebrew or Chocolatey.

Create a new folder using the terminal or Explorer and establish an npm project in it by typing npm init --yes into the terminal.

This will create a package.json file in the directory. Alternatively, you can use the package.json which i’m using (you’ll find the code on GitHub).

One little modification I like to do is to add the following to the scripts section in the package.json file:

“scripts”: {        
“cy:open”: “cypress open”,
“cy:run”: “cypress run”    
},

It allows me to open to run my cypress tests with the alternative command npm run cy:open for instance rather than npx cypress open.

Once you open the Cypress GUI runner. A cypress folder will be generated automatically with an example folder within the integration sub-folder. This is full of test specs useful for reference and learning from. But we can delete these as our tests won’t need them.

Making our request

Inside the integration folder. Create a new sub-folder called API. This is where we will store all of our API specific tests specs.

Next, we want to create separate files for each of the http methods that we will test (GET, PUT, POST, DELETE).

Open up the Get_Test.spec.js file.

We make API requests using the cy.request() call and the full syntax for the various commands can be seen here.

For this example, I will use the Docket web app to run my test against which is a simple application that allows for registering users and creating, changing and deleting to-do items via a REST API.

For this example, I have created some to-do items, just so that we have something to assert in our tests.

So walking through this code. On the first line I am referring to the Cypress library so VSCode can make use of Intellisense.

Next, I am using a describe block to describe the purpose of the tests in the file. I only have one test in this example. But if I was to include several more. The ‘describe’ block would explain to anyone that reviews my tests their overall intended purpose. Whereas the ‘it’ block on the next line is only used to describe the purpose of a single test.

The next few lines are dedicated to calling the API endpoint and passing in the required header object which contains an API key. All of this in in its own object.

Then finally, I am simply asserting the number of Todo items is what I am expecting.

Then when run, the result is a passing test and a lovely shade of green ?

Wrap up

Code for the remaining API methods has been added to GitHub here.

I referred to the documentation quite a lot when compiling the code for this example. Finding it not only simple to navigate, comprehensive with tonnes of example code and alternative use cases. It is also visually appealing and laid out well for intuitive understanding and easy to digest and learn from.

Being able to use Cypress for API testing just shows that Cypress has the ability to fill multiple slots in a testers toolbox.

I hope this was useful. Feel free to modify the code and show your own examples in the comments ?

• Category: Software Testing