Testing Web Apps with Cypress

Setup Cypress & Code

Steve Kinney

Steve Kinney

Testing Web Apps with Cypress

Check out a free preview of the full Testing Web Apps with Cypress course

The "Setup Cypress & Code" Lesson is part of the full, Testing Web Apps with Cypress course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses the ways Cypress can be installed and run. Cypress runs in a separate application. The first time it's opened, both a cypress directory and a cypress.json file are created in the project. A number of example test files are also added to the project.


Transcript from the "Setup Cypress & Code" Lesson

>> Let's go ahead and take it for a spin. So this is that kind of empty repo and you can see in package JSON I do have Cypress installed, there are under devdependencies, right there. There are a number of ways to install Cypress. I think you can brew, install with Homebrew.

I think there's probably a Docker container, there's a bunch of stuff you can do. The recommended way if you look what we saw on the website we first visited. And if you go digging through the docs it's to npm install. Why? Well, one is that you will get a pinned version of it for everyone in your project using the same version, right?

So you don't have to hope if you Homebrew you gotta hope that everyone's got the same version. Two is that later when we set up a CI/CD pipeline, it is also easier to have that version in the repo kind of ready to go as well. Can you host all your Cypress sets in a different repo?

Totally, you could, right? That is going to kind of make it a little bit more difficult when you want to wire up CI/CD. But you can see a world that like at a large enough company, there are reasons why you might want to but in all those cases there's probably also reasons why you might not want to.

You could even see a world well you choose to do both where for your project you have Cypress kind of doing the major things around your project. And then maybe at a large company level there's a series of end to end tests that are taking Cypress across multiple teams applications, right?

There's nothing that ties it to one but like I said, in terms of working on your project and making sure everyone in your team is using the same version, and also the CI/CD piece of it. It behooves you to probably just npm install it and have a version ready to go in your package JSON.

All right, so barring some really great reason or opinion about why you should do it a different way, this is probably the paved path both in my opinion as well as for the Cypress team as well. Cool so with that in place let's actually get this started for the first time.

Now it has been npm installed. But beyond that, we've never run it before, right? And so Cypress has a binary called Cypress, seems like a good name for it. And there's basically two major ways of firing up Cypress, cypress open and cypress run. The core difference is cypress open is mostly the one that you want to use, especially when you are developing an application and working on stuff.

Cypress run is probably what your CI/CD process would like to run, right? It is the kind of headless mode that will instead of giving you anything that you can personally touch and poke around on if the tests aren't working it take screenshots and record videos. So you can triage it when the build fails or something along those lines.

So you could make a npm script or you can also just use MPX if you're using a version of npm from the last few years. MPX basically takes any of the binaries that are in your node modules and adds them to the path. So we could do MPX cypress open and that will spin up a Electron app For Cypress, and we're gonna get it for the very first time.

And there's a few things to notice about this. I'm just gonna make mine a little bit bigger but you can kinda do whatever you want in this case. One is it actually gave you a bunch of example test, right? Two is if kind of look in Visual Studio code I've got this green addition here which is a created a new directory.

Let's talk about the directory first and then we'll go back into the application. So in here we have fixtures Integration which are effectively our tests, plugins which we'll talk about a little bit and support which is kind of your utilities and other things that you might want to pull in for those tests.

So it we went ahead and it created all of this for you. You can see that those examples that we saw in the Electron app that spun up are mapped to these two directories of getting started with todo.spec, and then a whole bunch of other ones in these advanced examples.

You could either go ahead and delete these directories yourself, or if you go back to the Cypress application, you can see they are nice enough to go ahead. They put them there they are also nice enough to go ahead and delete them for if you don't want them, right?

It might be worthwhile to kind of poke around and see how a few of them work. And we're certainly going to do that before we hop into the other project that has kind of where we're actually doing most of our work today. So I'm not gonna touch that just yet.

The other kind of interesting thing is you can choose which browser that you want to drive, in my case, I'm gonna use Chrome for most of the day. But you can use Chrome and any of the Chromium browsers, right? So Chrome, Microsoft Edge, so on and so forth.

If you have a nightly build of Chrome also installed the computer, that will show up here as well. And you can see that there is support for Firefox as well. At this moment I do not think it supports Safari. But Firefox, Chrome and the Chromium family of browsers will work in this case as well.

There you can log in as well. There will be some things you might see for the very first time, for instance, if you hit Open in IDE, for you it might ask you to just let it know what your IDE of choice is, right? So any of the major ones are there Vim, VS Code, so on and so forth.

So that will work there as well. And the interesting part about Cypress that will kind of explore over the course of our time together is there is Cypress the test runner, right? But then a lot of the other pieces of Cypress are actually based on other open source testing tools.

So the syntax for your assertions and running the test are just Mocha and Chai. So if you already use those for your unit tests then when I say it is the same syntax, it is literally the same syntax. We'll get to the caveat to that sentence in a second.

But mostly the same syntax because it is Mocha and Chai. That said there might be a little bit of an impedance mismatch if you are using Jest but we'll talk about how autocomplete and IntelliSense is your friend in this case. And how to just navigate that without having to learn two tools at the same time.

But you can kinda see some of the popular things that we've seen in many of our testing frameworks, right? Like I said this is Mocha and Chai, you can even see with the IntelliSense TypeScript hints there but this looks indistinguishable from Jest in this case, right? So you can probably use either one.

The other interesting part is you've got this CY object which has a series of methods. And you can kinda see that it's gotta get where you give it a selector. And then you kinda chain it into a should that has whatever assertion you wanna do. There's the ability to get the first and last one.

Now, so my favorite things, which is the test runner is, again, the testing assertion piece, and then you describe and it blocks, so on, and so forth are Mocha and Chai, the selector engine. Would anyone like to take a wild guess what selector engine it's using under the hood?

>> jQuery.?
>> Yes, jQuery. It is using JQuery. So for some people that will be a return to a skill set that maybe they haven't gotten a chance to use it lately. For some of this insecurity, why is it like that, because effectively that is the JQuery under the hood.

So we'll see little pieces of that work as well but that's where the first and the last is coming from. You can again see that In the TypeScript hints where yes, it's a Cypress chainable but under the hood is JQuery doing this. You have all of the power of JQuery at your disposal to kind of run and drive your tests.

So JQuery, Mocha and Chai, for some of the glob stuff is mini match, which Isaac who created npm made. There's a bunch of libraries that Cypress sits on top of it. So, if you've used any of these tools in the past, you're already coming into this with some amount of knowledge of how to write Cypress test.

Cuz it's based a lot of ways on these same tools that building web applications is based on top of applications is based on top of. Like I said before, it is completely framework agnostic, right? If you're just going and clicking a button on the page to verify that does the thing you expect it to do, it does not matter if that button was built in React, or Spelt, or Ember, or what have you.

The button is on the page, so on and so forth. That's also great like I said before, if you have a code base that isn't a state of transition, right? You can actually maybe cover a lot of the current functionality and tests and then begin to do the refactor knowing that everything works the way that you expect it to.

One of the things kinda just pay kind of attention to is this chaining functionality in Cypress. It does take a little bit of getting used to, in a lot of ways they look like promises. There's some that actually have a then, I'm not sure if it's in this sample file, but they're not necessarily promises per se.

But this code looks synchronous, it's in fact a synchronous. There will be little things that we need to keep in mind as we go through all of that. But by the end we should begin to kind of get the sense of that as we go through everything.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now