A Cypress Developer’s Cheat Sheet
By: Marcelo Costa
Tags: Programming, JavaScript, Cypress, Testing, Front End Development

A Clean Package Structure

The proposed folders and files are presented below:

Cypress clean package structure

The integration , support , plugins , and fixtures folders come out of the box with Cypress. The new structure in our case is the pages_data and functions folder. they will take the role of the well-known page objects.

Did you notice the pizza word in the diagram above? That’s because we’ll be using the Angular Pizza Creator app.

Angular Pizza Creator Application — from cypress-repo-fork

Everyone loves pizza, right?

Let’s go back to the package structure explanation.

pages_data

The idea here is to not confuse it with the classical implementation of page objects, but you could name it virtually anything. Let’s see some code to understand better this class role:

We’re mainly using it to store the page elements selectors, but did you notice the APIs attribute?

Cypress has an amazing feature of stubbing network requests, and most of your UI tests should be leveraging this. In the Pizza application we only have one API call to showcase the structure, but let’s give some food for thought.

Imagine a fictional scenario, where you have more than ten API calls, and you have some CRUD capabilities, which calls the APIs with different HTTP verbs, GET/POST/PUT/DELETE. You can easily get to more than 50 JSON payloads that you will have to maintain, and, trust me, this can easily get messy.

So how do you organize it in a way that makes your life easier?

Let’s dig into the API’s attributes. Each API represents a StubbedAPI , and as you could see in the PizzaOrderPageData class, we have different API files for each context. In this case, we called them: view , edit , remove and create .

IPageData and StubbedAPI relationship

The StubbedAPI points to the response that will be returned. This way, it’s easier to understand the scenario and the page that the API call belongs to.

Here’s an example of one of the API files, used by the PizzaOrderPageData class:

One time we had one web application that consumed APIs using alpha versions. When we flipped from alpha to beta, there were major breaking changes, and this structure was really helpful in making those changes.

functions

Do you remember that statement from the Cypress guys, saying Page Objects should really be renamed to “Using functions and creating custom commands”?

So that’s the idea here. This functions layer main goal is reusing code needed to interact with the UI.

Created on imgflip

You might be asking yourself, “What’s the difference between this and using the classic Page Object pattern?”

There are so many interactions, components, events, and user roles within one UI, that it’s really hard to abstract all that into one Page Object.

So the difference here is that we are splitting the elements selectors from the functions, and by doing that we can try to get the best of both worlds. And please don’t create functions for every UI behavior; otherwise, we are doing the same as the Page Object. Only start creating functions for your spec file when you start repeating yourself.

Also, by using this standardized structure, we can create common functions like this:

Integration spec file

Now let’s take a look at what became of the pizza-order.spec :

If you want the full code, please go to this Github repo. You can also find there the plantuml files used to build the diagrams.