Javascript

How to Create a Custom Login Command with Cypress, React, & Auth0

Nov 18, 2022

6 min read

Auth0 is a tool for handling user authentication and account management. Cypress is a tool for writing end to end tests for your application.

Getting these two technologies to work together can have a few gotchas, especially if your application is set up to have the end to end tests in a separate folder from your frontend code. Today, we’ll go over the steps you’ll need to implement so you can have a custom Cypress command to log in a user, and also let your front end code continue to work safely!

Setup

For this setup, we're making the choice to keep our end to end tests in one folder, and our front end code in a sibling folder. You don't have to do it this way. It's just the choice we've made for this project. So our folder setup has two root level folders, "cypress" and "app":

cypress
| support
| cypress.config.ts
app
| tsconfig.ts
| src

React Adjustments

Auth0 provides a default login form for you to use. We’ll focus on the fact that the forms use web workers to store the user’s access tokens in memory. This helps them keep that access token more secure from attackers.

This is important to note for Cypress. But because Cypress does not have a way to interact with that web worker. So we need to be able to detect when our application is running the site through Cypress so we can adjust how we get the access token.

We’ll need to update the way our Auth0 form saves that token based on if our app is running normally, or if it’s running through Cypress. To do this, we can add a check to the cacheLocation prop in our Auth0Provider field that wraps around our root app component.

app/index.ts

<Auth0Provider
  domain={domain}
  clientId={clientId}
  audience={audience}
  redirectUri={window.location.origin}
  onRedirectCallback={onRedirectCallback}
  scope="openid email"
  useRefreshTokens
  cacheLocation={window.Cypress ? "localstorage" : "memory"}
>
  <App />
</Auth0Provider>

Important note if you’re using TypeScript: If your project is using TypeScript, there will be two more small changes you might need to make. First, your editor may be yelling at you that it doesn’t know what Cypress means, or that it doesn’t exist on the window interface. So you can make a type file to solve this.

src/types/globals.d.ts

  Interface Window {
    Cypress: boolean
  }

Then, in the root level tsconfig file, we need to add an option to the compilerOptions section so it knows to look for this file we just made and use it. Then your editor should be happy! :)

app/tsconfig.ts

  “compilerOptions”: {
    “typeRoots”: [“src/types/globals”]
  },

And that’s all your front end code should need to work! It’ll continue to work as expected when running your app locally or in production. But now when you run your Cypress tests, it’ll store that access token in local storage instead, so we can make use of that within our tests.

Cypress Adjustments

Now we can make our custom login command! Having a custom command for something like logging in a user that might need to be repeated before each step is super helpful. It makes it faster for your tests to get started, and doesn’t need to rely on the exact state of your UI so any UI changes you might make won’t affect this command.

There’s a few different things we’ll need to handle here:

Writing the custom command itself
Making an e2e file where we’ll set up this command to run before each test
Updating the Cypress config file to know about the environment variables we’ll need
If you’re using TypeScript, you’ll also need to make a separate “namespace” file and an index file to pull all the pieces together.

We’ll start with the meat of the project: making that custom command! I’ll share the whole command first. Then we’ll walk through the different sections individually to cover what’s going on with each part.

The Custom Command

Cypress automatically sets up a support folder for you, so you’ll likely already find a commands file in there. This will go in that file. If you don’t have it, you can create it!

cypress/support/commands.ts

1 /// <reference types="cypress" />
2 Cypress.Commands.add('loginWithAuth0', (username, password) => {
3 	const client_id = Cypress.env('auth0_client_id');
4 	const client_secret = Cypress.env('auth0_client_secret');
5 	const audience = Cypress.env('auth0_audience');
6 	const scope = Cypress.env('auth0_scope');
7
8 	cy.request({
9 		method: 'POST',
10 		url: `https://${Cypress.env('auth0_domain')}/oauth/token`,
11		body: {
12			grant_type: 'password',
13			username,
14			password,
15			audience,
16			scope,
17			client_id,
18			client_secret,
19		},
20	}).then(({ body }) => {
21		const { access_token, expires_in, id_token, token_type } = body;
22		cy.window().then((win) => {
23			win.localStorage.setItem(
24				`@@auth0spajs@@::${client_id}::${audience}::${scope}`,
25				JSON.stringify({
26					body: {
27						client_id,
28						access_token,
29						id_token,
30						scope,
31						expires_in,
32						token_type,
33						decodedToken: {
34							user: JSON.parse(
35								Buffer.from(id_token.split('.')[1], 'base64').toString('ascii')
36							),
37						},
38						audience,
39					},
40					expiresAt: Math.floor(Date.now() / 1000) + expires_in,
41				})
42			);
43		});
44	});
45	});

The first piece to note is line 2.

Cypress.Commands.add('loginWithAuth0', (username, password) => {...

This is what actually tells Cypress “hey, this is a command you can use”. The name can be anything you want. I’m using “loginWithAuth0”, but you could call it “login” or “kitty” or whatever makes the most sense for your project. Just make sure you know what it means! :)

Lines 3-6 are setting our the environment variables that the Auth0 call will use. Then, on line 8, we use Cypress to make the actual request to Auth0 that allows us to log in. For this use case, we’re choosing to login with a username and password, so we tell the call that we’re using the “password” type and send all the necessary environment variables for the call to work. (You can find info on what these values should be from the Auth0 docs.)

Then, on lines 20 and 21, we’re starting to deal with the response we get back. If the call was successful, this should contain the information on the test user we just signed in and the access token we need for them. So we extract those values from the body of the response so we can use them.

On line 22, we again use Cypress to get the browser’s window, and let us store the user access token. We'll use localStorage for this as seen on line 23.

Important note here!

Pay extra special attention to the way the string is set up that we’re storing in localStorage on line 24! Auth0 needs the access token to be stored in this specific manner. This is the only way it will find our token! So make sure yours is set up the same way.

The rest of the code here is taking the information we got from the Auth0 call and adding it to our new localStorage value. You’ll see that on line 35 we’re parsing the user information so we have access to that, and then setting an expiration on line 40 so the token won’t last forever.

And that’s it - our command is set up! Now on to the rest of the things we need to set up so we can actually use it. :)

Supporting Files

If you have commands that should be run before every test call, you can create an e2e file in your support folder. These are your global imports and functions that will apply to all of your Cypress test files.

Here we’ll import our custom commands file and actually call our new command in a beforeEach hook, passing in the test username and password we want to use.

cypress/support/e2e.ts

import "./commands";

beforeEach(function () {
  cy.loginWithAuth0(
    Cypress.env("auth0_username"),
    Cypress.env("auth0_password")
  );
});

TypeScript Note: To get the typings to work properly for your custom commands, you’ll need to do two things. First, you’ll want to make a new file called namespace in your “support” folder. Then, you’ll want to declare the Cypress namespace in there, and set up a line for your new custom command so Cypress knows the type for it. (If you originally edited the default Cypress commands file, you’ll also want to go to the bottom of that file and remove the namespace section from it - this is replacing that.)

declare namespace Cypress {
  interface Chainable {
    loginWithAuth0(username: string, password: string): Chainable<string>;
  }
}

Then in your support folder, create an “index.ts” file and add your commands and namespace imports to it.

  Import “./commands”;
  Import “./namespace”;

That should clear up any TypeScript related warnings in your files!

The final piece is updating our Cypress configuration file. We need to add all the environment variables we need in here so Cypress is aware of them and we don’t have them hard coded in our files.

cypress.config.ts

import { defineConfig } from "cypress";

require("dotenv").config();
export default defineConfig({
  e2e: {
    baseUrl: "http://localhost:3000",
  },
  env: {
    auth0_username: process.env.AUTH0_TEST_USERNAME,
    auth0_password: process.env.AUTH0_TEST_PASSWORD,
    auth0_domain: process.env.AUTH0_DOMAIN,
    auth0_audience: process.env.AUTH0_AUDIENCE,
    auth0_scope: process.env.AUTH0_SCOPE,
    auth0_client_id: process.env.AUTH0_CLIENT_ID,
    auth0_client_secret: process.env.AUTH0_CLIENT_SECRET,
  },
});

Wrap Up

With that in place, you should be good to go! Whenever you run your Cypress tests now, you should see that a user is automatically logged in for you so you start on the first page of your app.

We hope this helps! If you run into any issues or have questions on anything, please feel free to reach out to us. Leave a comment on this post or ask in our Discord. We’ll be happy to help!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Linda Thompson

@lindakatcodes @lindakatcodes

How to test React custom hooks and components with Vitest

Introduction In this guide, we'll navigate through the process of testing React hooks and components using Vitest—a powerful JavaScript unit testing framework. Discover how Vitest simplifies testing setups, providing an optimal solution for both Vite-powered projects and beyond. Vitest is a javascript unit testing framework that aims to position itself as the Test Runner of choice for Vite projects and as a solid alternative even for projects not using Vite. Vitest was built primarily for Vite-powered projects, to help reduce the complexity of setting up testing with other testing frameworks like Jest. Vitest uses the same configuration of your App (through vite.config.js), sharing a common transformation pipeline during dev, build, and test time. Prerequisites This article assumes a solid understanding of React and frontend unit testing. Familiarity with tools like React Testing Library and JSDOM will enhance your grasp of the testing process with Vitest. Installation and configuration Let’s see how we can use Vitest for testing React custom hooks and components. But first, we will need to create a new project with Vite! If you already have an existing project, you can skip this step. ` Follow the prompts to create a new React project successfully. For testing, we need the following dependencies installed: Vitest as the unit testing framework JSDOM as the DOM environment for running our tests React Testing Library as the React testing utilities. To do so, we run the following command: ` Once we have those packages installed, we need to configure the vite.config.js file to run tests. By default, some of the extra configs we need to set up Vitest are not available in the Vite config types, so we will need the vite.config.ts file to reference Vitest types by adding /// reference types=”vitest” /> at the top of the file. Add the following code to the vite.config.ts ` We set globals to true because, by default, Vitest does not provide global APIs for explicitness. So with this set to true, we can use keywords like describe, test and it without needing to import them. To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json. ` The environment property tells Vitest which environment to run the test. We are using jsdom as the environment. The root property tells Vitest the root folder from where it should start looking for test files. We should add a script for running the test in package.json ` With all that configured, we can now start writing unit tests for customs hooks and React components. Writing test for custom hooks Let’s write a test for a simple useCounter hook that takes an initial value and returns the value, an increment function and a decrement function. ` We can write a test to check the default return values of the hook for value as below: ` To test if the hook works when we increment the value, we can use the act() method from @testing-library/react to simulate the increment function, as shown in the below test case: ` Kindly Note that you can't destructure the reactive properties of the result.current instance, or they will lose their reactivity. Testing hooks with asynchronous logic Now let’s test a more complex logic that contains asynchronous logic. Let’s write a useProducts hook that fetches data from an external api and return that value ` Now, let’s see what the test looks like: ` In the above example, we had to spy on the global fetch API, so that we can mock its return value. We wrapped that inside a beforeAll so that this runs before any test in this file. Then we added an afterAll method and called the mockRestore() to run after all test cases have been completed and return all mock implementations to their original function. We can also use the mockClear() method to clear all the mock's information, such as the number of calls and the mock's results. This method is handy when mocking the same function with different return values for different tests. We usually use mockClear() in beforeEach() or afterEach() methods to ensure our test is isolated completely. Then in our test case, we used a waitFor(), to wait for the return value to be resolved. Writing test for components Like Jest, Vitest provides assertion methods (matchers) to use with the expect methods for asserting values, but to test DOM elements easily, we will need to make use of custom matchers such as toBeInTheDocument() or toHaveTextContent(). Luckily the Vitest API is mostly compatible with the Jest API, making it possible to reuse many tools originally built for Jest. For such methods, we can install the @testing-library/jest-dom package and extend the expect method from Vitest to include the assertion methods in matchers from this package. ` After installing the jest-dom testing library package, create a file named vitest-setup.ts on the root of the project and import the following into the project to extend js-dom custom matchers: ` Since we are using typescript, we also need to include our setup file in our tsconfig.json: ` In vite.config.ts, we need to add the vitest-setup.ts file to the test.setupFiles field: ` Now let’s test the Products.tsx component: ` We start by spying and mocking the useProducts hook with vi.spyOn() method from Vitest: ` Now, we render the Products component using the render method from @testing-library/react and assert that the component renders the list of products as expected and also the product has the title as follows: ` In the above code, we use the render method from @testing-library/react to render the component and this returns some useful methods we can use to extract information from the component like getByTestId and getByText. The getByTestId method will retrieve the element whose data-testid attribute value equals product-list, and we can then assert its children to equal the length of our mocked items array. Using data-testid attribute values is a good practice for identifying a DOM element for testing purposes and avoiding affecting the component's implementation in production and tests. We also used the getByText method to find a text in the rendered component. We were able to call the toBeInTheDocument() because we extended the matchers to work with Vitest earlier. Here is what the full test looks like: ` Conclusion In this article, we delved into the world of testing React hooks and components using Vitest, a versatile JavaScript unit testing framework. We walked through the installation and configuration process, ensuring compatibility with React, JSDOM, and React Testing Library. The comprehensive guide covered writing tests for custom hooks, including handling asynchronous logic, and testing React components, leveraging custom matchers for DOM assertions. By adopting Vitest, developers can streamline the testing process for their React applications, whether powered by Vite or not. The framework's seamless integration with Vite projects simplifies the setup, reducing the complexities associated with other testing tools like Jest....

Mar 15, 2024

5 mins

ViteReactTesting

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

In this episode of the Modern Web Podcast, hosts Tracy Lee, Ben Lesh, and Adam Rackis kick things off by discussing the progress of observables landing in the browser and the potential impact it could have on the use of RXJS. As developers, we're always on the lookout for new tools and technologies that can make our lives easier, and observables in the browser certainly have the potential to do just that. They talk about whether or not you should listen to your “customers” or have a strong vision that you want to push forward, like Ryan Carniato and his approach with Solid and Signals. The three also talk about AI tools, such as GPT and Co-Pilot, and how they are shaping the future of coding and ideation. Finally, Ben, Adam, and Tracy briefly touch on the potential impact of automation on job roles and the outsourcing of tech jobs. While automation can streamline certain tasks, it's important to remember that human creativity and problem-solving skills are irreplaceable. Download this episode here!...

Feb 16, 2024

1 min

ReactRxJSArtificial Intelligence

Content Projection in Angular

Imagine yourself at a movie theater. No matter what theater you go to, or what movie you see, you'll notice some very similar things - most notably, the large screen the movie plays on. This screen is an excellent example of a reusable object - it can show any movie projected onto it! The screen doesn't need to know the details of the movie it's playing - all it does is show whatever content is projected onto it. This is a similar idea to how content projection works in web development! Today, we'll go over what content projection looks like and how you can use it to make components that are reusable and less tied to the data they display. We'll be using Angular for these examples, but any framework you'd like to use likely has a way to do this as well! If you'd like to view the source code for these examples, you can check them out in this Stackblitz editor. Single slot projection The simplest way to do content projection is to use a single "slot" or area where we pass data in. Note that you're not limited on what data you pass in - you could provide as much data as you wanted in here. But your component that's handling the content projection uses a single slot for all that data. Using the movie example above, let's create a simple "screen" that will display a random cat GIF, and some "now playing" text with it. For the screen component, the HTML will be very simple - just a section container and a special Angular tag called ng-content. This element acts as a placeholder for the content that will be passed into it, and does not create a DOM element itself. It tells the component that we expect some data in an unknown shape to be shown in it's place. ` Then, in our main app component, we can send this screen the data we want it to show! ` And that's it - our single-screen component will display the GIF and title! Multi-slot projection Sometimes, it can be useful to designate some of the data that gets projected into certain sections of our component. In the previous example, we could have the "Now Playing" text set up almost anywhere - it could be on the top of the screen, the bottom, over the image itself. Even though we're projecting data into our component, we can designate some sections with a particular name, so when we write the content that gets sent to the component, we can tell it where to go. If we wanted to set up our screen so that it always shows the name first and then the image in our component, we would specify the select value on the ng-content tag. If we want one of these tags to be the default value, we can leave its select value empty. ` Then, when we add this tag to our main app, we'll see the data in the order our component says it should show, no matter what order we type it in. ` In conclusion This topic can be as simple or as complex as you need it to. There's tons of great use cases for content projection. You could use it to create reusable layouts, as an expansion toggle wrapper around different lists of data, or to create reusable designed pieces that can take in whatever type of data you'd like. If you're interested in some more complex examples, I'd highly recommend checking out the Angular documentation for this subject. Can you think of other great use cases? Let us know! Demo...

Jan 4, 2022

3 mins

AngularTypeScriptWeb Development

Transforming Auth in an AI World with Rod Boothby

In today's digital landscape, the need for secure identity verification has become paramount. With the increasing risks of personal data exposure and the rise of sophisticated cyber threats aided by Artificial Intelligence, it is crucial to adopt robust verification processes to protect individuals and organizations alike. In a recent discussion with Rod Boothby, CEO of ID Partner Systems, the significance of trusted institutions for identity verification was emphasized, particularly the efficiency of bank-based ID verification over traditional methods. One of the key takeaways from the conversation was the importance of continuous authentication. As technology advances, so do the methods employed by cybercriminals. Deepfake technology, for instance, poses a significant threat to identity verification systems. To combat this, tighter security measures and continuous authentication are essential. By constantly verifying and validating user identities, organizations can stay one step ahead of potential fraudsters. Rod Boothby also highlighted the need for a developer-focused approach to identity verification. By providing developers with the tools and resources they need, companies like ID Partner Systems aim to streamline the verification process and enhance security. This approach not only ensures a more efficient experience for users but also allows for the integration of behavioral biometrics, which can further strengthen the verification process. Download this episode here....

Apr 22, 2024

1 min

Engineering Leadership

How to Create a Custom Login Command with Cypress, React, & Auth0

Setup

React Adjustments

Cypress Adjustments

The Custom Command

Important note here!

Supporting Files

Wrap Up

Linda Thompson

You might also like

How to test React custom hooks and components with Vitest

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Content Projection in Angular

Transforming Auth in an AI World with Rod Boothby

You might also like

How to test React custom hooks and components with Vitest

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Content Projection in Angular

Transforming Auth in an AI World with Rod Boothby