Why we should start writing our visual unit tests with CypressImage composed by Aphinya Dechalert. Titled: the big experiment known as the front end.

Why we should start writing our visual unit tests with Cypress

how to drive your frontend projects with tests that matter

Aphinya Dechalert
May 20 · 5 min read

Unit testing is all great until something changes. The current issue with writing traditional unit tests is that you miss out on the point of front end development — to create experiences for the end user. While unit tests may do very well in determining if an input produces an expected output, it only captures moment in time rather than a complete flow of actual events.

This is where Cypress excels, especially in the end-to-end space.

e2e is easier to validate a user’s experience and their interaction with an application. This makes it a good supplement to existing unit tests. While larger enterprises may have their own QA teams, e2e tests at the developer level makes coding driven by design rather than an additional checkpoint at the end.

Performance wise, it is easy to implement and have the potential to run tests in parallel — meaning, that multiple scenarios and outcomes can be tested simultaneously with auto reloading and snapshots for developers to debug if such an event should arise.

Cypress has solid documentation with event driven language for their syntax, making the task of writing tests more akin to actual user flows and potential interactions than just testing x and y. The visual nature of Cypress differentiates it from other unit testing and e2e suites currently available, giving the developer the ability to visually check the user experience with DOM state snapshots and historical contexts against different executions.

This makes Cypress a powerfully easy tool to use and lowers the bar of entry significantly for developers wanting to drive their development efforts with tests, catching bugs before they morph into something too big.

How to use Cypress with Nx

Before we proceed, Nx stands for Nrwl Extensions for Angular and is built by a team of ex-Google employees who were also part of the Angular core team. Nx isn’t a replacement of the Angular CLI and instead extends it.

Nx sits on top of the CLI and works to give your application access to features and functionality currently not available in the CLI. It has the ability to create work spaces, along with applications and libraries — thus expanding the CLI’s capabilities.

So how do we use Nx with Cypress? and why should we?

Using Cypress with Angular CLI is possible but there is a lot of manual set up required. Nrwl Nx solves this problem by creating streamlined experience that pre-configures all you need for Cypress to work.

To use Nrwl Nx, you’ll need to install it using the following command in your console:

After this has installed, you’ll need to create a workspace using command:

This will give you a series of questions before creating your workspace. If you select Angular in the question that asks ‘what to create in the new workspace’, it will begin to set everything up for you. Nx will create a folder called and inside this folder, there will be an apps folder. In this apps folder, you will find an empty Angular project and a Cypress ready e2e test unit.

Nx also supports React, so React developers are not left out from this out of the box set up.

For Angular, to run the testing suit, be sure to navigate into the workspace folder and use the command below:

The flag lets you write you tests in the background and Cypress automatically detects any changes in the test or application code and runs itself against the changes.

Example usage and cases

Accessing store

Cypress is able to test a multitude of front end frameworks and libraries, Redux being one of them. By using inside your , you are exposing the store when the application is run inside Cypress’ browser.

Now inside your test file, you can test the store’s state through

Here’s an example of accessing a store and testing if it has a specific item.

it(‘has expected state on load’, () => { 
cy.visit(‘/’)
cy.window()
.its(‘store’)
.invoke(‘getState’)
.should(
‘deep.equal’,
{ list: [ { text: ‘by apples’, } ] }
)
})

button clicked

Attaching a attribute to a button exposes the item for testing by Cypress. While this is not necessary as it can be accessed through classes, it is not recommended as it can result in the wrong object being targeted. therefore makes certain for Cypress that it is testing the right thing.

For example, your HTML button code may look something like this:

<button id="main" class="btn" data-cy="submit">
Submit Me!
</button>

To create a test to check if the button is clicked, your Cypress test code may look something like this:

cy.get(‘[data-cy=submit]’).click()// ORcy.contains(‘Submit Me!’).click()

Potential issues when using Cypress

The concept of code coverage refers to the percentage of code that is covered my automated tests. Purity of test types may get muddied and percentage of test coverage may reduce over time when teams begin to mix and math e2e with unit tests.

The coverage therefore gets thinned over time and may leave pockets untested as a result. Certain pipelines may only pass a project to the next stage if it passes a percentage of tests — tests that may may not account for e2e results or are exclusively e2e.

Another potential issue is that test hooks have the potential to muddy up the final production code. The idea of hooks is to keep the main code state untouched and independent from actions that are trying to observe events, inputs, outputs and outcomes.

Extended Features

Cypress’ test runner is MIT open sourced and free. However, it does have a commercial side to it and offers a Dashboard service allows you to centralize your tests and enable continuous integration at a team level. This differs from the test runner which only runs on your local machine.

There is a free Seed tier that currently allows for up to 3 users and 500 test recordings. As you move up through the plans, the level of support, users and number of test recordings increases.

Final words

Cypress as a testing tool differs from all other testing tools, frameworks and assertion libraries because it offers front end developers a way to test their applications that is driven by user experience.

Creating unit tests can be a dry process but Cypress brings the fun and beauty of creating visuals without having to manually click the buttons yourself every time to test if something worked. The DOM snapshots makes for fantastic debugging and the concise, yet information rich, documentation also helps in the learning process.

Setting up is quick and it doesn’t take long at all to get started on Cypress.


Thank you for reading. ❤

Aphinya

Razroo

UI Architecture

Aphinya Dechalert

Written by

I‘m taking a personal depth year. Follow me to follow my journey. I’m also writing a book. Tweet/DM me for the free copy when it’s ready. dottedsquirrel.com

Razroo

Razroo

UI Architecture

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade