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.
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.
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.