Want to write test cases with JavaScript? Say hello to Cypress.io!

From the start of my time writing software, I knew I wanted to work with JavaScript. It does what I need, has a really robust community, and there doesn’t seem to be an end to the number of resources out there. One of the things I’ve always wanted to do for my personal code was to write test cases. Having the peace of mind that new features don’t break older code is well worth the energy in my opinion. Thankfully, I found cypress!

Cypress is a testing tool that allows you to write all your tests using plain old JavaScript. For me, this is a game changer. I can now write all my tests using a language I already use daily. Want to start using it too? I will show you how below!

Installation

In order to get started, we will need to install cypress into our project. I created a boilerplate NuxtJS project for the purposes of this article, so I will be installing cypress there. Open up your project in terminal (I am doing this on a mac), and enter the command shown below.

This will install cypress into our project. Next up, we will want to update our package.json file, so that cypress can be run with a simple command.

Now, inside terminal you can start cypress by simply running the following command: ‘npm run cypress:open’

To verify this all works, run both your project (For me, it is npm run dev), as well as your cypress environment using the command we made above. If everything worked, you should see cypress open!

Writing a simple test

In our project directory, we should see a cypress folder at our root. Inside it, there should be a series of subfolders. The one we care about for writing our tests is the integration folder. This is where we will add our test files. It is good practice to name your files specific to what you are testing. Since my project directory is strictly for this tutorial, I named my file test.spec.js.

Before we start writing our tests, we should come up with a game plan. We should check to ensure that when the visitor makes their way to our page, the URL is correct, and that the title of our page is correct. The page we are checking is shown below.

We should write our tests in a way that seems logical, and that would mimic what a user would do under normal circumstances. Under normal circumstances a user isn’t going to verify the url, since they just visited the page and know where they are. This is more for the developers sake.

Our test will do the following:
– Visit the page to ensure it loads
– Check on our URL hostname, port, and protocol for accuracy
– Check on the title.
Now that we have a plan of action, we want to write our test.

One of the nice things about Cypress is it does things in the order given, and lays it out nicely. When compared to our test above, it’s easy to follow. If there had been a failure, we could track it down fairly easily. As a developer, I choose tools that streamline my job and make my life easier. Cypress succeeds in this area.

Had there been a failure, it would show us the point of failure. I went ahead and updated our test case to the following to show a failure.

Why did this fail? In our environment, we take advantage of port 3000. Cypress knows this, and the test is failing out. As we see below “expected ‘3000’ to equal ‘3001’”, which makes no logical sense.

                            

This becomes extremely beneficial as more and more tests are written. Some tests can be extremely complicated, especially once you start checking queries, mutations, and all kinds of complicated business logic. The easier the tools make things, the better off you are.

Documentation

One of the best parts of Cypress is the documentation. The documentation for it is top notch. It is clear, concise, and full of examples that make sense. As a developer, having poorly written docs is a huge turn off for me when choosing what to use in my project. I don’t want to have to scour the Internet in order to find a solution for every problem. I love being able to go to the official page and find what I am looking for.

If you’d like to read the official documentation, it can be located here.

IDE Extensions

For those who use VSC, here are a couple of extensions to make your life easier.

– Cypress-Helper
– Cypress Fixture-IntelliSense
– Open Cypress

Final Thoughts

I plan on building onto this and making it into a series. I will go over testing GraphQL, testing various data, and mocking user behavior on more complex pages. Let me know your thoughts and if there are any topics around end-to-end testing you’d like to see.

The Author: Jeremy Grice. If you’d like to follow me, here are my Twitter, Medium, and GitHub accounts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s