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)

Install, Configure, and Script Cypress for JavaScript Web Applications

 Test User Registration with Cypress

Instructor: 00:01 There's one feature about my app that I definitely want to test and that is the register link. If I click on that then I can fill out a username of ABC and then a password of 123. I hit submit and that takes me to the app again except now I had this logout button. Then when I click on that I can log out and then login again.

00:17 Let's go ahead and test this registration process. I'm going to add a new file in `e2e` called `register.js` and here I'm going to `describe` registration and then we'll have a test called `it` should register a new user and with this we're going to need a user object so we'll say username is Bob and password is yoh.

#### register.js
```js
describe('registration', () => {
  it('should register a new user', () => {
    const user = {username: 'bob', password: 'yo'}
  })
})
```

00:37 Except that's not going to work very well because every single time I run the test, I'm going to try and register a new user with the username of Bob and that's not going to work because we'll already have a user in the database. Now, clearing out your database between tests is a good thing to do, but sometimes you can't do that. There's a really easy way to avoid this problem altogether.

00:55 What we're going to do is in my `support` directory, and I create a new file called `generate.js`. I'm going to `import {build, fake} from 'test-data-bot'`, which I already have installed, and then we're going to make a `buildUser` function from build user. I give that label.

01:12 The fields for our user will include a `username`, which is a `fake` username using faker to get an Internet username. Then we'll have a `password` with `fake` faker fake Internet password, and then we'll `export` that `buildUser`.

#### generate.js
```js
import {build, fake} from 'test-data-bot'

const buildUser = build('User').fields({
  username: fake(f => f.internet.userName()),
  password: fake(f => f.internet.password()),
})

export {buildUser}
```

01:29 Cool. Now, I can now go back over to `register.js` and will `import {buildUser} from '../support/generate'`. With that now, instead of hand-coding a user, we'll just call our `buildUser` in our function, and then we'll start out our test. We'll say `cy.visit` the app and we'll save this.

#### register.js
```js
describe('registration', () => {
  it('should register a new user', () => {
    const user = buildUser()

    cy.visit('/')
  })
})
```

01:45 Now we can see our tests are running, and we have this should register a new user and we visit the app.

![tests are running](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1574727282/transcript-images/cypress-test-user-registration-with-cypress-tests-are-running.png)

Now, we want to click on register and we'll fill out the username, password, and then click on submit.

01:55 Back in `register.js`, we will `findByText`, `register`. Case doesn't matter, so I'll do that. I flag for our rejects, we'll `click` on that and we'll `findByLabelText`, `username`, case doesn't matter there, and we'll `type` in the `user.username`. Then we'll `findByLabelText` here.

02:12 For the `password`, ignore case there, and `type` the `user.password`. Then we'll `findByText`, `submit`, and we'll `click` on that submit button.

```js
import {buildUser} from '../support/generate'

describe('registration', () => {
  it('should register a new user', () => {
    const user = buildUser()
    cy.visit('/')
      .findByText(/register/i)
      .click()
      .findByLabelText(/username/i)
      .type(user.username)
      .findByLabelText(/password/i)
      .type(user.password)
      .findByText(/submit/i)
      .click()
  })
})
```

Let's go ahead and save that and see our test run and it does!

02:25 What are the assertions that we want to make here? When we register a new user, if we open up our Dev tools, go to application, and then click on local storage, we notice that we have a token in here, so we want to verify that token exists, and we also want to verify that we get redirected to the home screen.

02:40 What we need to do is change our subject to the URL so we can make an assertion on that. We'll say `.url()` and all that does is it changes the change subject for cypress to the URL. We can make an assertion that it `should`, `'eq', 'http://localhost:8080/'`.

02:57 Then we want to get the localStorage value for token. We're going to change the subject to `window()` and we'll say it's `localStorage.token` value `should` be a string.

```js
describe('registration', () => {
  it('should register a new user', () => {
    const user = buildUser()
    cy.visit('/')
      .findByText(/register/i)
      .click()
      .findByLabelText(/username/i)
      .type(user.username)
      .findByLabelText(/password/i)
      .type(user.password)
      .findByText(/submit/i)
      .click()
      .url()
      .should('eq', `http://localhost:8080`)
      .window()
      .its('localStorage.token')
      .should('be.a', 'string')
  })
})
```

Save that, come back here, and we get our test running and everything's passing.

03:17 I'm satisfied to know that the localStorage value is a string, especially since your test will typically continue doing things that only authenticated users would be able to do. This assertion is enough for me because if the localStorage token is not a string, then I'll get an early error. If it doesn't work at all, then I'll know that I have a problem with my authentication.

03:35 One other thing that I want to change here is I don't like hard coding this value, `'http://localhost:8080'`, so I'm going to get rid of this. We'll do `Cypress.config().baseUrl`, we'll end that with a slash and that assertion looks a little bit cleaner.

```js
describe('registration', () => {
  it('should register a new user', () => {
    const user = buildUser()
    cy.visit('/')
      .findByText(/register/i)
      .click()
      .findByLabelText(/username/i)
      .type(user.username)
      .findByLabelText(/password/i)
      .type(user.password)
      .findByText(/submit/i)
      .click()
      .url()
      .should('eq', `${Cypress.config().baseUrl}/`)
      .window()
      .its('localStorage.token')
      .should('be.a', 'string')
  })
})
```

We don't have to hard code that baseUrl everywhere.

03:49 In review, what we did here was we created a generate file to generate us a user. Then we created a register file, so we can have a test of the registration process. We created a new user. Then we visited the app, clicked on the registration link, filled in the username and password, clicked on submit, and then verified that the URL changed to the home URL and that the window localStorage token is a string.

04:12 One thing that I want to add here is that if your registration process sends out an email and then user can't do anything until they've confirmed their email address, it's a good idea to just mark that service out entirely for your test. Writing an automated test for something like that would be very non-trivial and would only give you a little bit extra confidence.

04:29 I'd recommend marking that out so that your end-to-end test can continue on without having to worry about that email. As with everything else, testing is just a bucket of tradeoffs and you can make the tradeoffs that you feel comfortable with.


 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

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.

Script Cypress for Local Development and Continuous Integration

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

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.

Test User Registration with Cypress

Transcript

Test User Registration with Cypress