We want to make starting cypress as simple as possible for local development and we need to be able to run a single script that exits when the tests are complete for continuous integration. So let’s add a few scripts to get ourselves setup for this development experience.

Install, Configure, and Script Cypress for JavaScript Web Applications

Script Cypress for Local Development and Continuous Integration

Instructor: 00:01 When I want to run my Cypress end to end test, I first have to run my server and then I have to run `npx cypress open` or if I want to run it headlessly, then I run `run` command. It'd be really great if I could just run one script and it would start up my server and start up Cypress automatically.

00:16 That's what we're going to do. We'll `npm install` as a devDependency `start-server-and-test`. 

#### Terminal
```bash
npm install --save-dev start-server-and-test
```

With that installed, I'm now going to add a couple of scripts in out `package.json`. Just below `test:debug`, I'm going to add a `test:e2e`.

#### package.json
```json
"test:e2e": ""
```

00:32 What this script is going to do is pretty similar to my `"test"` script at the top. We'll do our `is-ci` and if we are on CI, then we'll have a `test:ete:run` script. That will run our Cypress in headless mode, otherwise, we're local and so we'll `test:e2e:dev`.

```json
"test:e2e": "is-ci \"test:e2e:run\" \"test:e2e:dev\""
```

00:49 Let's go ahead and create `test:e2e:run`. With that, we're going to run `start-server-and-test`. 

```json
"test:e2e:run": "start-server-and-test"
```

This script takes a couple of arguments. The first argument is the NPM script that we want to have run. We'll call that one `start` and we already have that set up for us automatically right here to start our app in production mode.

01:09 I'll have server and test run the start script and then we'll have `start-server-and-test` look for our app listening for traffic on port 8080. When that address starts accepting traffic, we'll run `cy:run`, so I'll need to create that script.

```json
"test:e2e:run": "start-server-and-test start http://localhost:8080 cy:run"
```

01:23 Let's go ahead and do that. `cy:run`, what this is going to run is `cypress run`. That runs Cypress in headless mode, which is good for CI. 

```json
"cy:run": "cypress run"
```

We're going to do something similar for our dev script, so I'll just copy `test:e2e:run`. Instead of `run`, we'll have it be `dev` and instead of `cy:run`, we'll have it be `cy:open`. We'll have our `cy:open`, which will run `cypress open`.

01:43 Of course, we want this `dev` to run the `dev` script. As soon as our dev script server is accepting traffic at port 8080, then we'll run cy open, which will open the Cypress app and we can start developing with Cypress.

```json
"cy:run": "cypress run",
"cy:open": "cypress open",
"test:e2e": "is-ci \"test:e2e:run\" \"test:e2e:dev\"",
"test:e2e:run": "start-server-and-test start http://localhost:8080 cy:run",
"test:e2e:dev": "start-server-and-test dev http://localhost:8080 cy:open",
```

01:56 One thing about this is that the `dev` script is going to start our node server and our webpack dev server in development mode, but the `start` script is going to run all the built code. We want to make sure that our test are running across the freshest version of our built code.

02:09 I'm going to add a script that runs before `run`, leveraging a feature of NPM by doing `pre` and then the name of the script. NPM will automatically run this script before it runs the script of the same name. The script that I wanted to run is `npm run build`. In that way, we have a fresh build of the app before we try to test the build version of the app.

```json
"pretest:e2e:run": "npm run build",
```

02:29 With all that set up, I'm going to come down here to my `validate` script and we're going to add `npm run test:e2e:run` because this is what's running on CI. 

```json
"validate": "npm run test:coverage && npm run test:e2e:run",
```

I also want to come down to my `husky` configuration here for my `"pre-commit"` script and we'll add an `npm run test:e2e:run`.

```json
"husky": {
  "hooks": {
    "pre-commit": "lint-staged && npm run test:e2e:run"
  }
}
```

02:46 I'm only doing this because this is a pretty small project and the end to end test don't take a whole lot of time to run. As your project grows, your end to end test suite gets bigger and takes longer to run. This might add significant overhead to the pre-commit script. I'd probably get rid of this and just rely more on CI.

03:02 One other thing that we need to configure about CI is in our `.travis.yml` here. We need to make sure that Travis installs a package that Cypress depends on, so add `addons` configuration here and we'll use `apt,` `packages`. The package is `libgconf-2-4`.

03:18 We also want to make sure that we're caching the directory that Cypress is saved into, so do `~tilde/.cache`. In that way, we don't have to wait for Cypress to install every time.

#### .travis.yml
```yml
addons: 
  apt: 
    packages:
      - libgconf-2-4

cache: 
  directories:
    - ~/.npm
    - ~/.cache
```

03:28 With all of those changes, now if we run `npm run test:e2e`, that will determine are we on CI? Oh no, we're not so we're going to run the dev script and we'll open up the Cypress app so we can develop with Cypress. With that, now we can click on `run all specs` and we've got our test running and passing. Excellent.

03:48 Let's take a look what this looks like. If we were to run this on CI. If I run `npm run test:e2e:run`, then that's going to run our build first and then it's going to run our node server and then it's going to run Cypress run, which will pick up all of our test and run our test in headless mode. As soon as our test all pass, `start-server-and-test` is going to shut down our server.

04:12 In review to make all of this magic happen, we created a bunch of scripts right here using the `start-server-and-test` module so we could have a development mode for developing our application with the Cypress app using cy open, which runs Cypress open.

04:25 As well as running our test across the built version of the code with our start script and `cy:run`, which runs Cypress in headless mode with the run command. With that, we have the NPM run build, which happens before the test:ete:run so we make sure that we're testing the latest version of our code.

04:43 We also updated our Travis configuration to install dependencies that Cypress has and to cache the Cypress binary that's downloaded. We also updated our validate script, so that we would run our end to end test in CI. Because this is a pretty small project, we also added the test:ete:run script to our pre-commit hook in our configuration for Husky.

 is an incredibly powerful web testing tool. It’s capable of testing any web application. Its architecture places it a cut above similar end-to-end testing tools. Its developer experience is best-in-class. And because Cypress runs your tests in the same context as the rest of your application, you’re able to get speed, reliability, and debuggability that are just a long - distant dream with similar tools. The catch? There is no catch. Cypress is exceptional.

In this course, we’ll go over how you can install, configure, and script Cypress to test modern, real - world JavaScript web applications.

What's changed in Install, Configure, and Script Cypress for JavaScript Web Applications

Intro to Install, Configure, and Script Cypress for JavaScript Web Applications 

Despite the fact that Cypress is an application that runs natively on your machine, you can install it and add it as a dependency just like all other dependencies in your package.json file. So let's install Cypress and get our project ready to start end-to-end testing with Cypress.

Install and Run Cypress

Cypress starts out your project with a ton of tests, let’s remove those and add our first test that verifies our calculator can add two numbers together using the Cypress selector playground and Cypress commands.

Write the First Cypress Test

Cypress is fairly simple to configure, but it’s important to optimize our experience in testing Cypress. We’ll configure the baseUrl to make it easier to visit our app and we’ll also move our test files to a folder called e2e to make it more clear what types of tests we want to write with Cypress. We’ll use the cypress.json file, but Cypress can also be configured via command line flags and environment variables.

Configure Cypress in cypress.json

Our selectors are pretty ridiculous, mostly because we’re using CSS-in-JS and css modules for our react application. But even if we weren’t, using class names as selectors for our application testing is pretty brittle and not really testing in the way a user would. So instead let’s use cypress-testing-library to improve our selectors and make it easier to read our tests.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Installing Cypress Testing Library

One of the greatest features of Cypress is how awesome the experience of debugging tests is. You do have to get used to the asynchronous nature of E2E testing, but once you get the hang of that debugging is pretty straightforward, and the ability to debug your own source code is awesome. The fact that your test and source code are executed in the same context also gives you some powerful advantages as well. You can potentially even expose some internal state to your Cypress app.

Debug a Test with Cypress

Let’s write a test to fill out our registration form. Because we’ll be running this against a live backend, we need to generate the user’s information to avoid re-runs from trying to create new users that already exist. There are trade-offs with this approach. You should probably also clean out the application database before all of your tests start (how you accomplish this is pretty application-specific). Also, if your application requires email confirmation, I recommend you mock that on the backend and automatically set the user as confirmed during tests.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

 Test User Registration with Cypress

Because Cypress allows you to use all the developer tools you’re used to from Google Chrome, you can actually use Cypress as your main application development workflow. If you’ve ever tried to develop a feature that required you to be in a certain state you’ve probably felt the pain of repeatedly refreshing the page and clicking around to get into that state. Instead, you can use cypress to do that and developer your application entirely in Cypress.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Cypress Driven Development

Normally I prefer to test error states using integration or unit tests, but there are some situations where it can be really useful to mock out a response to test a specific scenario in an E2E test. Let’s use the cypress server and route commands to mock a response from our registration request to test the error state.

Simulate HTTP Errors in Cypress Tests

To test user login we need to have a user to login with. We could seed the database with a user and that may be the right choice for your application. In our case though we’ll just go through the registration process again and then login as the user and make the same assertions we made for registration.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Test User Login with Cypress

We’re duplicating a lot of logic between our registration and login tests and not getting any additional confidence, so lets reduce the duplicate logic and time in our tests using cy.request to get a user registered rather than clicking through the application to register a new user.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Create a User with cy.request from Cypress

We’re going to need a newly created user for several tests so let’s move our cy.request command to register a new user into a custom Cypress command so we can use that wherever we need a new user.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Keep Tests Isolated and Focused with Custom Cypress Commands

Use Custom Cypress Command for Reusable Assertions

For most applications you’re going to need to be logged in as a user to interact with the application. Let’s see how we can register as a new user and login as that user to test using the application as a logged in user.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Run Tests as an Authenticated User with Cypress

We’re duplicating a bunch of commands between our new test and the login test and it’s not giving us any more confidence that the application is working properly. So let’s do the same thing we did with registration and make a cy.request command to login with the newly created user to speed up our test and make it more focused.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Use cy.request from Cypress to Authenticate as a New User

It’s pretty likely that we’ll need to login as a particular user for many tests, let’s take our cy.request command and turn it into a custom command to make it easier for the places we’ll be needing a logged in user.

There's been a small breaking change to Cypress Testing Library that affects the code in this video. [Learn more here.](https://github.com/testing-library/cypress-testing-library/releases/tag/v6.0.0)

Use a Custom Cypress Command to Login as a User

Combine Custom Cypress Commands into a Single Custom Command

Because Cypress runs in a real Chrome browser, we can install extensions, like React DevTools. The tricky bit will be to make our application hook up to the extension properly.

Script Cypress for Local Development and Continuous Integration

Transcript

Script Cypress for Local Development and Continuous Integration