dan-lourenco

Guest Author

Dan Lourenco

Learn how to programmatically authenticate against Auth0 in your Cypress tests in a manner that adheres to both Cypress and Auth0 best practices.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Important Announcement</strong><br> 
  <b>This blog post is no longer maintained and it may be out of date</b>. Please use the following resources created by the Cypress team to learn how to use Cypress to test a Single-Page Application (SPA) that uses Auth0: 

  * <a href="https://cypress.io/blog/2022/04/25/cypress-9-6-0-easily-test-multi-domain-workflows-with-cy-origin/">Cypress 9.6.0: Easily test multi-domain workflows with cy.origin</a> (Blog post)
  * <a href="https://www.youtube.com/watch?v=Fohrq5GZSD8">How to test multiple domains or origins with Cypress</a> (Video) <br>

<br />
<iframe width="560" height="315" src="https://www.youtube.com/embed/Fohrq5GZSD8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>

**TL;DR:** This post discusses how to authenticate against Auth0 in your Cypress end-to-end tests successfully. You will use a small sample React application to illustrate patterns you can use to programmatically log your user into Auth0 while running Cypress tests, in a manner that adheres to most Cypress and Auth0 best practices. To see a working example of the techniques described in this article, please feel free to clone [this repo](https://github.com/dlo83/auth0-cypress-demo).

<include src="TweetQuote" quoteText="Learn how to perform end-to-end integration tests on SPAs secured with Auth0."/>

## Prerequisites

As mentioned, you will be using a React application written with modern JavaScript language features (ES2015+), so a good understanding of modern web technologies is recommended. If you’re not quite there yet, there are a wealth of fantastic resources for modern JS development, including courses from [Wes Bos](https://es6.io/), [Tyler McGinnis](https://tylermcginnis.com/), and others.

You will also need to have Node.js and NPM installed. [Check out the Node.js website](https://nodejs.org/en/download/) for download links and an installation guide.

You are also expected to have an Auth0 account and have valid user permissions so that you can authenticate into your application. So, if you don't have an Auth0 account yet, <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free now</a>.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

Lastly, a basic understanding of what Cypress is and why it’s useful is expected. If you do not know Cypress, check out [this article](https://auth0.com/blog/cypress-write-automated-tests-to-validate-web-applications/) for more.

## Auth0 Setup & Configuration

To see the whole process in action, you will need to create an Auth0 Application on your Auth0 dashboard. To do so, head to [the Applications section of your dashboard](https://manage.auth0.com/#/applications) and click on the _Create Application_ button. When you click on this button, you will see a dialog. On this dialog, you will have to add a name for your application (e.g., "Cypress E2E Testing") and you will have to select _Single Page Web App_ as its type.

Now, clicking on the _Create_ button will make Auth0 redirect you to the _Quick Start_ page of your new application. From there, you can head to the _Settings_ tab and configure it as follows:

* Scroll down to the _Allowed Callback URLs_ field and enter in the following value: `http://localhost:3000/callback`. After user authentication occurs, Auth0 will only redirect successfully if the route in question is listed here.
* Enter `http://localhost:3000` into the **Allowed Web Origin** field.
* Enter `http://localhost:3000` into the **Allowed Logout URLs** field.
* Scroll down to the bottom of the **Settings** page and click **Show Advanced Settings**.
* Click on the **Grant Types** tab, and check the **Password** grant.
* Click **Save Changes**.

Now, you can create a user account for the end-to-end testing scripts. To do so, head to [the _Users_ section of your dashboard](https://manage.auth0.com/#/users) and click on _Create User_. On the dialog shown by Auth0, fill the form as follows:

* _Email_: Enter a random email address (e.g., `e2e-testing@mydomain.com`)
* _Password_: Enter a random password (e.g., `s#m3R4nd0m-pass`)
* _Repeat Password_: Enter the same password.
* _Connection_: Use the `Username-Password-Authentication`

After that, click on _Save_ to finish the process.

Lastly, you will have to go to [your tenant's settings](https://manage.auth0.com/#/tenant) and set `Username-Password-Authentication` as the value of the _Default Directory_ property. As mentioned in this page, this field defines the "name of the connection to be used for Password Grant exchanges". In this case, the `Username-Password-Authentication` value comes from the default the default [_Database Connections_](https://manage.auth0.com/#/connections/database) that Auth0 adds to all new tenants.

![Auth0's default database connection.](https://images.ctfassets.net/23aumh6u8s0i/WIYNDHA9YBusXqhZJn13E/f3750b39784c88804197a33f7b728e5b/auth0-default-database-connection)

Just don't forget to save the changes made to your tenant.

## The Sample App

First things first, clone [this repo](https://github.com/dlo83/auth0-cypress-demo) and check out the `base` branch:

```bash
# clone the repo
git clone https://github.com/dlo83/auth0-cypress-demo.git

# move into it
cd auth0-cypress-demo

# checkout the base branch
git checkout base
```

> **Note:** You can also refer to the finished product on the `master` branch. Then, be sure to `npm install` and `npm run start` in your terminal to spin up the application.

This app will be quite simple: it is a React application with a few routes, powered by React Router 4. One of the routes will be protected — that is, only accessible for authenticated users — and the other, public.

There will be one other route which serves an important purpose: the `/callback` route. This route is where the user is redirected after successfully entering their Auth0 credentials. When this route is hit, the application checks to ensure that the state information in the URL's query string matches the state stored in the persisted cookie.

If these protected route patterns are unfamiliar to you, I highly recommend checking out [Bruno Krebs' article](https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/) for more.

## Cypress

Cypress is a modern front-end testing tool that makes writing integration tests a breeze. This tool is, essentially, a one-stop shop for all your end-to-end testing needs, combining a _fast_, state-of-the-art testing framework, graphical and headless test runners, and easy-to-use assertion library in one package.

### Authentication with Cypress

So you’re sold on Cypress and you’re using Auth0 for your authentication needs. Now, it is time to see how you can make the two play nicely together!

Imagine that you want to write a test to ensure that a user can visit a page only available behind authentication. How would you do this?

The naive approach would be to:

* Visit the web application and invoke a redirect to the Auth0 login page (via a button click, route change, etc.)
* Enter in your Auth0 username and password
* Submit the form
* Wait for the redirect to your web application and proceed as needed

There’s a problem with this, though. To paraphrase co-founder of Cypress, [Brian Mann](https://github.com/cypress-io/cypress/issues/1342#issuecomment-366747803):

> The best practice is never to visit or test third-party sites over which you have no control.

Then, since you don’t have control over the Auth0 website, it doesn’t make sense to try and mimic a user’s login flow through the UI.

So what do you have to do?

<include src="TweetQuote" quoteText="Don't waste time covering services that you do not control on your end-to-end tests."/>

### Cypress Best Practices

Thankfully, a Cypress contains an [example recipe](https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/logging-in__single-sign-on) that can help you. The general pattern for dealing with Single Sign-On authentication is as follows:

*  Use Cypress’ `cy.request()` command to make an HTTP request to your authentication service (in this case, Auth0)
*  Parse the tokens in the response
*  Set tokens on local storage

> **Note:** Auth0 now recommends [using cookies in lieu of local storage](https://auth0.com/docs/security/store-tokens#don-t-store-tokens-in-local-storage). Not a problem. You will adhere to this recommendation in your implementation.

Now that you have a strategy in place, you can get started.

### Cypress Commands

As stated above, your first course of action is to make an HTTP request against Auth0 using Cypress `cy.request()` command. A request with Cypress would look something like this:

```javascript
const options = {
  method: 'POST',
    url: 'https://my.url.com/endpoint',

    body: {
      username: 'my_username'
      password: 'my_password'
      ...
    }
}

cy.request(options)
```

That's great and all, but you can imagine that having to write the code above every time you want to log in could be quite cumbersome and violate DRY (Don't Repeat Yourself) principles. Thankfully, Cypress has a feature called [Custom Commands](https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax) that allow you to encapsulate this code and make it reusable across your tests.

So, insert the following code to the end of the `cypress/support/commands.js` file:

```javascript
Cypress.Commands.add('login', (overrides = {}) => {
  Cypress.log({
    name: 'loginViaAuth0',
  });

  const options = {
    method: 'POST',
    url: Cypress.env('auth_url'),
    body: {
      grant_type: 'password',
      username: Cypress.env('auth_username'),
      password: Cypress.env('auth_password'),
      audience: Cypress.env('auth_audience'),
      scope: 'openid profile email',
      client_id: Cypress.env('auth_client_id'),
      client_secret: Cypress.env('auth_client_secret'),
    },
  };
  cy.request(options);
});
```

Now, when you want to trigger a request to authenticate against Auth0, you simply have to call `cy.login()` from your code. The custom command name to use in your consuming code (in this case, `login`) corresponds to the first argument given to the `add()` method.

OK, so you have your custom Cypress login command, but what's with the `Cypress.env` values for the keys in the body object?

### Cypress Environment Variables

Because you re providing sensitive information in your Cypress request to Auth0, you need to authenticate. And, it's imperative to store this information outside of your test suite.

At the root of your project, create a file called `cypress.env.json` and, before populating this file, add this line to your `.gitignore` file:

```gitignore
cypress.env.json
```

This ensures that you do not accidentally commit any sensitive details to your Git repository. _Please, **do not forget** this step!_

Now, back in your `cypress.env.json` file, add the following code to it:

```json
{
  "auth_audience": "https://my_tenant.auth0.com/api/v2/",
  "auth_url": "https://my_tenant.auth0.com/oauth/token",
  "auth_client_id": "my_client_id",
  "auth_client_secret": "my_client_secret",
  "auth_username": "my_username",
  "auth_password": "my_password"
}
```

You will have to update each one of the properties above with your own Auth0 values:

- `auth_audience`: For this one, you will have to replace `my_tenant.auth0.com` with your own Auth0 domain (e.g., `blog-samples.auth0.com`). You can find this information on the Auth0 application you created before.
- `auth_url`: Here, you will have to do the same thing. You will have to replace `my_tenant.auth0.com` with your own Auth0 domain.
- `auth_client_id`: In this case, you will have to use the _Client ID_ property of the Auth0 Application you created before.
- `auth_client_secret`: Lastly, for this property, you will have to use the _Client Secret_ property of the Auth0 Application you created.

![Copying the Auth0 Application properties to configure your Cypress end-to-end testing scripts.](https://images.ctfassets.net/23aumh6u8s0i/1zI1K62EuZ5hEcDcV3BgzK/f72c67890bb1f3358df8f731429806e6/copying-auth0-application-properties)

For the last two properties (`auth_username` and `auth_password`) you will have to use the credentials used while creating the end-to-end testing user.

### Configure React App Environment Variables

Cypress isn't the only tool in your application that has to take environment variables. You will have to define environment variables for your React application as well, albeit in a different file.

* Rename the `.env.sample` file in the root of the project to simply `.env`.
* Replace the `my-tenant.auth0.com` value (on the `REACT_APP_AUTH0_DOMAIN` variable) with your tenant domain (e.g., `blog-samples.auth0.com`).
* Insert your _Client ID_ for the `REACT_APP_AUTH0_CLIENT_ID` variable. Unlike the `cypress.env.json` file, there should be no quotes around this value here.

### Grant Strategies

While creating your Auth0 Application, you enabled the Password grant. But what exactly is a grant, anyway?

[Auth0](https://auth0.com/docs/applications/application-grant-types) defines a grant as follows:

> OAuth 2.0 supports several types of grants, which are methods by which you can gain access tokens. Different grant types allow different types of access and, based on the needs of your app, some grant types are more appropriate than others.

That last sentence is the key here. Normally, when authenticating with Auth0, you are redirected to log in through Auth0's hosted login page. *But*, since you are in a testing environment (and again, you don't want to test what you don't control), you have to find some other way to authenticate against Auth0 without redirecting away from your application. That's where the Password Grant comes in. The Password grant relies on authenticating a user via provided username and password credentials.

## Writing tests using Cypress Login Command

OK. You have created your Cypress Custom Command for login. Also, you have configured your Auth0 account and you have updated your Cypress environment variables. Now, you will see how you can take advantage of everything you've done to log into Auth0 programmatically using Cypress!

In your project, create a new directory called `integration` inside `cypress`. Then, add a file called `login.js` to it with the following code:

```javascript
describe('login', () => {
  it('should successfully log into our app', () => {
    cy.login()
      .then((resp) => {
        return resp.body;
      })
      .then((body) => {
        const {access_token, expires_in, id_token} = body;
        const auth0State = {
          nonce: '',
          state: 'some-random-state'
        };
        const callbackUrl = `/callback#access_token=${access_token}&scope=openid&id_token=${id_token}&expires_in=${expires_in}&token_type=Bearer&state=${auth0State.state}`;
        cy.visit(callbackUrl, {
          onBeforeLoad(win) {
            win.document.cookie = 'com.auth0.auth.some-random-state=' + JSON.stringify(auth0State);
          }
        });
      })
  });
});
```

Now, in your terminal, run the following commands from the root directory of your React project:

```bash
# install all dependencies
npm install

# run the React app on the background
npm start &

# run cypress
npm run cypress:open
```

This will make the Cypress dashboard open.

![Cypress dashboard](https://images.ctfassets.net/23aumh6u8s0i/1JdvnCY4VmEIXOFCmuoFqo/bdcdf89014bc58b285c1b2fc08ec6a21/running-the-cypress-dashboard)

From there, you can click on the `login.js` integration test in the Cypress test runner. You should now see an instance of Chrome launched, with your user automatically logged in to Auth0! Click on the **Profile** page to see your logged in user's email address for verification.

![Running the E2E testing scripts with Cypress and Auth0.](https://images.ctfassets.net/23aumh6u8s0i/4ZSK4oPQf8PXPlld8b81bI/d3a85580fa2ebc214bcab7df9d43d484/running-the-e2e-testing-scripts-with-cypress-and-auth0)

<include src="TweetQuote" quoteText="I just learned how to perform end-to-end integration tests on SPAs secured with Auth0."/>

## Wrap Up

In this article, you started by learning about one of Cypress' core tenets when it comes to testing: avoid testing sites over which one does not have control. Next, you took a quick look on _Cypress Custom Commands_ and how they make your lives easier by encapsulating repetitive testing logic. Then, you learned about _Grant Strategies_, which are methods by which you can gain access tokens. More specifically, you learned about the _Resource Owner Password Grant_ strategy, which allows you to receive a token by providing username and password credentials, thereby circumventing the need to visit the Auth0 login page.

> **Note:** Keep in mind that you must not use this grant on your public clients. This is an exception to this rule because it is an end-to-end test that won't be used by real users.

Finally, you learned about how you can use your custom login command in a test, set your access token in memory, and successfully log into your application as part of your Cypress test.

I hope you've enjoyed reading this article, and have gained an understanding of how you can incorporate Cypress into your Auth0 application. If you have any questions or concerns, please feel free to leave a comment down below.

Thanks for reading!


End-to-End Testing with Cypress and Auth0

rama

Learn how to use Cypress to write automated tests that run on browsers to validate web applications.



**TL;DR:** This post is an introduction on using [Cypress](https://www.cypress.io/) for writing browser-based automation tests for web applications. This tutorial uses a React application as an example to illustrate the testing framework, but you can apply the learnings to write integration tests for any web application.

The source code for the React application and the corresponding Cypress tests are available in [this repository](https://github.com/auth0-blog/cypress-todo-example). The `master` branch contains the code needed to start this tutorial and [the `cypress-tests` branch](https://github.com/auth0-blog/cypress-todo-example/tree/cypress-tests) contains the final setup with all Cypress tests.

<include src="TweetQuote" quoteText="Learn how to use Cypress to write end-to-end tests that help you validate your web application automatically."/>

## The Test Pyramid and Importance of E2E tests

A typical test suite for your application can generally consist of three layers (you could have many more depending on the nature of the application):

* [Unit tests](http://softwaretestingfundamentals.com/unit-testing/).
* [Integration tests](https://en.wikipedia.org/wiki/Integration_testing).
* [End-to-end tests](https://www.techopedia.com/definition/7035/end-to-end-test).

![The Test Pyramid and Importance of E2E tests](https://images.ctfassets.net/23aumh6u8s0i/28IDUQHtX8rB8liLirJ0VJ/0fbe2806cebb60ca5ddfbc2089e5a84c/the-test-pyramid)

Numerous tools and libraries help you write tests that offer a safety net to your application at each of the layers listed above. But, when it comes to the level of redundancy to test coverage and which layer should assert what, the following two rules might help:

1. Write tests with different granularity.
2. The more high-level you get the fewer tests you should have.

Also, the feedback cycle for tests in each of the layers can vary. The unit tests offer the lowest latency on feedback and the latency increases as you go up the pyramid. For this post, we will focus on E2E tests and specifically on [user interface tests](https://en.wikipedia.org/wiki/Graphical_user_interface_testing).

User Interface (UI) tests, or UI tests, are tests that use the system just like a real user would interact with the application on the browser. They use scripts to mimic users' actions and they basically interact with the app just as a regular user would. Cypress is one of the many web automation tools available to help you write effective user interface tests.

## How Is Cypress Different as a UI Testing Tool?

Most browser-based automation tools are [selenium-based](https://www.seleniumhq.org/), which works by implementing a web driver that remotely executes commands on the browser through the network. Whereas, Cypress runs in the same run-loop as your parent application. Also, Cypress tests are only written in JavaScript. While you can compile down to JavaScript from any other language, ultimately the test code is executed inside the browser itself.

These architectural improvements unlock the ability to run tests much faster in browser mode as well as headless mode. You can read more about [the internal details of Cypress here](https://www.cypress.io/how-it-works/). As you start writing more Cypress tests and build the pipeline with a test suite, you will see that many aspects of writing automation tests have improved with this library.

## Writing Your First Cypress Test

To see Cypress in action, you will take advantage of an existing to-do app written with React. Don't worry if you don't have experience with React per se. Cypress can be used with any other front-end technology like Vue.js or Angular and you will use an existing React app here just to avoid having to set up too much stuff before diving into Cypress.

Below, you can see a screenshot of the application that you are going to use while learning about Cypress.

![Sample To-Do application that you will test with Cypress.](https://images.ctfassets.net/23aumh6u8s0i/4sZJzojOW8NRT05wRdVDT5/562abacd448bab8b9c3ad0368ff1430c/sample-todo-app)

As you can see, this app has a list of to-do items that are either open or completed. A to-do item can be completed or deleted using the action icons present on the item. The text field and the button can be used to add a new to-do item.

To get started, you will first clone the sample application and install its dependencies:

```bash
git clone https://github.com/auth0-blog/cypress-todo-example.git
cd cypress-todo-example
yarn install
```

> **Note:** You could easily use `npm` instead of `yarn`. It is more a matter of taste here.

When you are done installing all the dependencies, run `yarn start` to run the application in the browser to make sure it looks good. The same application is also available in [codesandbox](https://codesandbox.io/s/4j5m27o8ox) if you have trouble running it on your machine.

Now, you will bootstrap Cypress and write your first test. With the application running, open another terminal session and run the following commands inside the same folder (`cypress-todo-example`):

```bash
yarn add --dev cypress
yarn cypress open
```

Cypress will sense that you are running it for the first time and create a folder called `cypress` with necessary files to get you going. It would also launch the cypress test runner. Think of it as a GUI for running/debugging your automation specs.

After that, you will create a file called `todo_spec.js` in the `cypress/integration` directory. You might need a third terminal for this (one for running the sample, one for Cypress, and one for creating new files. Or, even better, you can use an IDE like WebStorm or Visual Studio Code for this last task.

> **Note:** You should already see an `example_spec.js `file that contains tests for the sample [Kitchen Sink](https://example.cypress.io/) application with plenty of documentation for various scenarios. It is recommended that you read through the file at a later point in time for reference.

In this new file, add the following code:

```javascript
//cypress/integration/todo_spec.js

describe('Todo App', function () {
  it('.should() - allow adding a new todo item', function () {
    cy.visit('http://localhost:3000');
    cy.get('input[data-cy=newItemField]').type('Write Test');
    cy.get('#addBtn').click();

    cy.get('tr[data-cy=todoItem]:nth-child(1)').should('contain', 'Write Test')
  })
});
```

The test is pretty self-explanatory. It just connects to your app (`cy.visit('http://localhost:3000');`), then it types `'Write Test'` to the `input[data-cy=newItemField]` field, then it clicks on the `#addBtn` button so it can validate that the first `tr` element contains the `'Write Test'` string.

The `cy` variable that you are using to interact with your application is a global Cypress object that drives the tests. It has various helper methods to visit web pages, interact with web elements, and also to fetch data present in the DOM.

To learn more, you can check the [excellent documentation on Cypress](https://docs.cypress.io/guides/overview/why-cypress.html) and [the sample application](https://example.cypress.io/) that you would be frequently referring to as you add more test cases to your application.

Also, note that Cypress bundles the [`chai`](https://docs.cypress.io/api/commands/should.html#Syntax) assertion library and the matchers you see in the test is chained to the Cypress helper methods seamlessly for readability.

## Using the Cypress Test Runner

When you have saved the`todo_spec.js` file, it will start appearing in the Cypress test runner.

![New spec appearing the Cypress test runner.](https://images.ctfassets.net/23aumh6u8s0i/62NdUKoFsd0T2KhdJvwDcg/449de3c81a1952ce6781e21b828e8f11/cypress-test-runner)

When you click on `todo_spec.js` in the test runner, a new browser instance will open up and run the test visually. You can observe Cypress hop through each step that you wrote in the `todo_spec.js` test.

If everything works properly (as it should), you will see something similar to this screen:

![Automated tests running on Cypress.](https://images.ctfassets.net/23aumh6u8s0i/11NI2jceF7Fz8WV6hM8t5m/ba0fc92d520dcd31a7c8c84bc6b55b04/showing-e2e-tests-written-with-cypress-in-action)

The left pane is called the _Command Log_ and lists the name of the test followed by each step in sequence and its outcome. When the test runs, you can see Cypress interacting with the application on the browser webview to the right and you see that the new todo item is added to the list successfully. Lastly, you can see that the last step on the left is the assertion to verify if our new item is present in the list.

One very helpful feature on the browser view is the DOM selector that is shown highlighted below the internal URL address bar (not the real one from the browser, but the one from the inner browser). It will appear when you click on the _Open Selector Playground_ icon to the left of this address bar. You can type in a selector in the textbox like you have entered `#addBtn` and Cypress will highlight the selected item for you. Or you can select an element from the screen and Cypress will try to find the optimal selector for you to use in your test.

## Setting up Continuous Integration for Cypress

The whole point of writing and maintaining browser-based automation tests is to test the application for any flows that break and give early feedback to the team. You can set up the suite of Cypress tests to run on your continuous integration (CI) server to run on every check-in or as a nightly build.

In this section, you will go through the steps needed to set up the build and to any particular CI tool.

Most CI build agents are servers and not workstations, so you cannot expect them to have a GUI or X Window system to launch a real browser UI. So, it is a common practice to run web automation tests in [headless mode](https://en.wikipedia.org/wiki/Headless_browser). To keep it simple, you will use a virtual GUI buffer like [`xvfb`](http://elementalselenium.com/tips/38-headless) to fire a web browser virtually, launch the target application, and run Cypress tests against it.

Assuming, you are setting up a Docker agent on the CI server to run the tests, this is the specification for the `Dockerfile`:

```dockerfile
FROM cypress/base

// Clone your code base here

RUN npm install
RUN $(npm bin)/cypress run
```

Refer to this [page](https://docs.cypress.io/guides/guides/continuous-integration.html#) for setting up Cypress on your favorite CI server.

<include src="TweetQuote" quoteText="Cypress can be easily integrated into continuous integration tools to validate your web apps on each development iteration."/>

## Time Travel and Debugging with Cypress

Another cool feature present in the Cypress Test Runner tool is that as you hover through the command log on the left, for each step in the test, you can check the state of the application on the right. You can also click on the pin icon to freeze the runner for that particular step, open the developer console and get insights into the specific web interactions that happened, the selectors used, parameters passed and results.

![Time travel and debugging with Cypress](https://images.ctfassets.net/23aumh6u8s0i/2taPSrwfWdsc5ZPbNrWClB/8c2f4ba5ca25566e439afdc0129c71fa/time-travel)

<include src="TweetQuote" quoteText="Testing web applications with Cypress is awesome because you even get access to features like time travel."/>

## Postmortem Analysis on Cypress

The last thing you want with a browser automation test is false positives. By that, a test case failing because of the way the automation test was written and not because something in the actual application is broken. When that frequently happens, the test suite loses its credibility and a red build is not worth its attention anymore!

So, when a test fails on the CI, you need enough trails and artifacts to understand what really went wrong. Like most automation frameworks in the market, Cypress generates screenshots and videos of the entire test runs if configured correctly. All of these settings can be tweaked using the `cypress.json` configuration file generated in the root of your project. By default, screenshots and video recording are turned on and you can see them generated inside the `cypress` folder after running the tests.

Check out the [configuration documentation](https://docs.cypress.io/guides/references/configuration.html#Videos) for additional settings and options.

<include src="asides/JavascriptAtAuth0" />

## Conclusion and Further Reading

As you could see throughout this article, Cypress is an amazing tool that facilitates end-to-end tests on web applications. If you want to learn more about Cypress, the following list will lead you to some references that you might find useful:

1. [Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html).
2. [Most common Selenium challenges](https://crossbrowsertesting.com/blog/selenium/problems-selenium-webdriver/).
3. [Cypress architecture](https://www.cypress.io/how-it-works/).


"automated-tests"